Featured post

The 5 Whys

This deceptively simple technique can help you uncover a whole host of information and help you get at the actual problem the business is needing to be addressed. The process is simple to use. You simply ask why to every statement the business stakeholder is making regarding the issue at hand. Although the name is ‘5 whys’ it may take you less than 5 or many more than 5 to get at the heart of the problem.

5-why-with-girl

When to Use a 5 Whys Analysis

This technique can be used for troubleshooting, quality improvement, and problem solving, but it is most effective when used to resolve simple or moderately difficult problems.  If your problem is complex, this may not be the best technique to use because it does take you down a single or limited number of paths when you may need to consider multiple areas to solve the problem.

5 Whys does, however, partner well with other analysis techniques and is often used at the beginning of the analysis journey to help focus on where additional deep dives are needed.

 

Resources

https://www.mindtools.com/pages/article/newTMC_5W.htm

Featured post

Citizen Developers Wear Many Hats

As a citizen developer I may be called upon to wear many hats – analyst, designer, developer, tester, trainer.  Each hat requires its own set of skills and tools. In future posts we will explore each area in depth so you will have the tools you need to be a successful citizen developer.

wizardhat2

Analyst Hat

When wearing this hat, citizen developers work closely with business

partners and stakeholders to understand what the business needs to meet its goals and support its vision.  We also work closely with our technology partners in converting high level business initiatives into clear requirements that can be design, developed and implemented.

HatRed1

Designer Hat

When wearing this hat, citizen developers help determine the shape of the solution that will be developed and implemented.

hardhat

Developer Hat

When wearing this hat, citizen developers along with technology partners develop the solution.

BaseballCapBlackTester

Tester Hat

When wearing this hat, citizen developers test what has been

developed to be sure everything is working properly and meets the business’s needs.

 

Hat1

Trainer Hat

When wearing this hat, citizen developers provide training to their users on all the standard and custom functionality available.

 

 

 

Non-functional Requirements

A non-functional requirement (NFR) describes a feature or trait that defines a system’s state of being.

NFRs are

  • expressed in the form of “system shall be <requirement>”, an overall property of the system as a whole or of a particular aspect and not a specific function
  • Called “quality attributes”, “qualities”, “quality goals”, “quality of service requirements”, “constraints”, “non-behavior requirements”, “technical requirements”
  • Can be categorized as either
    • execution qualities (safety, security, usability) which are observable during operations (at run time)
    • evolution qualities (testability, maintainability, scalability) which are embodied in the static structure of the system

It is important to understand various types of NFRs, if they apply to your specific project and what questions can be used to help elicit and define non-functional requirements.

Different teams will group NFRs into different categories based on what they are producing, what they are familiar with, etc.  Some groupings today are:

  • FURPS – Functionality, Usability, Reliability, Performance, Supportability
  • RASUL – Reliability, Availability, Servicability, Usability, Installability
  • IIBA Supports – Reliability, Performance, Efficiency, Operability, Security, Compatibility, Maintainability, Transferability

I will be covering a number of NFRs to help you understand each of them and provide questions you should be asking and example statements in future posts.

NFR wrong-way

MOST

MOST Analysis is performed during strategic analysis to evaluate an organisations overall strategy, the supporting activities and whether they are all in alignment.

These are the four tiers in MOST Analysis:

  • Mission: defines what business the organisation is in and what it is intending to achieve
  • Objectives: key goals against which the organisations achievement can be measured
  • Strategy: the medium to long-term approach chosen to achieve organisational objectives
  • Tactics: the short-term, operational plans and projects that will implement the strategy

With this understanding of the current internal environment, the MOST Analysis technique analyse an organisation from its business strategy through to the way in it is setting about tactically achieving it.

MOST

Now, let’s explain each of the factors with their purposes.

Mission: This is the most critical factor for an organization which defines its purpose and the goals it wants to achieve in the future. If the mission is specific, then it is easier to analyze and measure the remaining factors.

ObjectivesWe can consider objectives as a collection of goals which as an accumulated result in the mission of the organization. Moreover, Objectives must be S.M.A.R.T –

  • S- Specific
  • M-Measurable
  • A-Achievable
  • R-Realistic
  • T-Timely

Strategy: This is the steps or actions that an organization takes to achieve the objectives and finally to accomplish the mission. A strategy is a group of tactics.

Tactics: These are the discrete and straightforward methods which an organization follows to carry out the strategies.

From <https://www.whizlabs.com/blog/best-business-analysis-techniques/>

PESTLE

The strategic analysis technique called PESTLE evaluates external factors that could impact business performance. The acronym stands for six elements affecting business: political, economic, technological, environmental, legal, and sociological.

PESTLE analysis assesses the possible factors within each category, as well as their potential impact, duration of effect, type of impact (i.e., negative or positive), and level of importance.

This type of business analysis helps stakeholders manage risk, strategically plan and review business goals and performance, and potentially gain an advantage over competitors.

pestle-analysis-diagram

As citizen developers we will probably not be too involved at this level of analysis for most projects but it never hurts to understand how all these areas affect what the business is asking to be done.

This information is provided from the following resources:

https://www.whizlabs.com/blog/best-business-analysis-techniques/

https://www.lucidchart.com/blog/business-analysis-models

Analysis Overview

Analysis is the practice of enabling change in an organizational context, by defining needs and recommending solutions that deliver value to stakeholders. Analysis can be strategic or tactical in nature.  Strategic analysis is focused on the big picture while tactical analysis is focused on solving a specific problem or opportunity.

In this post we will be touch upon a variety of analysis techniques to help us understand what the need or problem is so that we can then determine the best way to solve it.  What is listed is by no means all possible analysis techniques but only those I have found useful in some way.

clipboard2

The foremost priority for any business analyst will be to try understanding following things

  • Understand what business does and how it does
  • Determine how to improve existing business processes
  • Identify the steps or tasks to support the implementation of new features
  • Design the new features to implement
  • Analyze the impact of implementing new features
  • Implement the new features

The mechanism to accomplishes these activities is through analysis techniques.  These techniques can be grouped as either strategic or tactical. Below is a breakdown of the two categories. The techniques lists are by no means an exhaustive list.

Business report

Strategic Techniques

Strategic Analysis defines opportunities, and develops business cases to initiate work.  From an Agile point of view this level of analysis defines problems and opportunities in terms of themes and business epics.   Performing business analysis at a strategic level requires a broad set of tools and techniques to ensure that work initiated from the defined business cases support the organization’s business goals and objectives.

This level of analysis really has nothing to do with software development so, as citizen developers, we are usually not involved in this level of analysis. Not being directly involved doesn’t mean we shouldn’t at least be aware of some of the techniques that can be used for this level of analysis.

Some of the most popular techniques are:

  • PESTLE
  • MOST
  • SWOT
  • Product Roadmaps
  • CATWOE
  • Brainstorming

 

person holding blue ballpoint pen on white notebook

Photo by Lukas on Pexels.com

Tactical Business Analysis

The primary focus of tactical business analysis is to clarify the business epics or business cases that were defined through strategic business analysis.  This form of analysis is to elicit stakeholder requirements based on the business case.  In agile methodology the analyst decomposes business epics into features which are further decomposed into user stories.  It is at this level of analysis the citizen developer is mostly involved.

Just as there are many ways to design a solution to a problem, there are many ways to learn about a problem.  Different ways or techniques will provide you with a different way to see the problem.  Sometimes it may take several techniques to understand the problem.

Some of the most popular techniques are:

  • The 5 Whys
  • Mind Mapping
  • Business Process Modelling
  • Entity Relationship Diagram
  • Non-Functional Requirements Analysis
  • Wireframes

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.