Categories
Change Management Engagement Management Software Development

So, You Want What?

Facebooktwittergoogle_plusredditpinterestlinkedinmail
Communication with Vision Variance

The swing picture has been circulating for years and we all still laugh at this picture, because it is still so true. Everyone who works on projects can relate to it. Yet if we know this happens, why is it so difficult to make a change?

English: The Universal Language

The customer speaks English. I write in English. Developers read English. Where is the confusion? What is the problem? Well, still the widget is not doing what is needed. This is because it is easy to believe everything is clear, yet there is still misunderstanding. Take for example the following statements:

1. “We need to produce a Minimally Viable Product(MVP).”

  • The application functions?
  • Oh, you want user tracking and analytics too?
  • You need email marketing automated?

Minimal needs clarification. If something is required, state it as required. On some projects I have provided a raking from Required to Nice to have.

2. “We have doubled our impressions”

  • Twice as many people are thinking highly of us?
  • Twice as many people are visiting our site?
  • Twice as many people saw our ad?
  • Our advertising is working?

English terminology can be different. Depending on the audience, clarification of terms and what they mean, or do not mean, could be useful.

3. “Take it EZ. “

  • Do not worry about it?
  • Only put in 4 hours of work today?
  • Do not work past 9 PM?
  • Sit around and watch TV?

People have preconceived ideas about what this means.

4. “There is no hurry on that”

  • Whenever I get to it is fine?
  • You need it today, but not right now?
  • You need it in the next hour, but not the next minute?

Without clarity on this one you could really get you into some trouble.

5. “What are possible solutions?”

  • Option A
  • Option B
  • Option C

Boss, “I like Options B.”

Contractor, “That one is not in scope. We can price that option for you.”

Boss, “Which possible solutions are in scope?”

Contractor, “Option A”

Here the contractor could stand to clarify the options as to what will add cost to the project.

The above examples point out how easy it is to state something clearly as we can all read what was written, but there can still be miscommunication.

Spending Less is Better!
(Or Maybe Not?)

A 2019 BMW Z4 is selling for $72,000. However, on the other side of town you can get the “exact same car” (color, model, features, etc…) from a different dealer for $65,000. Spending less is better.

It is the same with software. Spending less for the same thing is better. If you are looking at a finished product, such as Turbo Tax for Business, and you can pick up a copy for $99 or the same product at another store for $89, spending less is better.

Imagine a scenario where Company X has put together a document describing their widget requirements and asked for quotes from three different software companies. The three different companies all supply their price to deliver the widget. They tell Company X what they will charge for the work. Should Company X award their contract to the low bidder? Is spending less better?

The Lowest Cost Was More!

Think about the swing picture which everyone laughs about. Which block of the picture was being described by the requirements? Which block of the picture was estimated by each of the software companies? There may be three costs provided, but what they plan on providing may not match the widget Company X has in mind.

You can sit in a room with employees of Company X, discuss what is needed, and still everyone walks away with a slightly different picture or understanding of what is needed and how best to proceed. We have the meeting to clarify details and reach consensus, but there will still be variation. What is the variation and how important is the variation?

“I know that you believe that you understood what you think I said, but I am not sure that you realize that what you heard is not what I meant.” – Erik Jul

One meeting attendee may think the system is getting a blue widget. Another attendee may think the system is getting a round widget. It may be the case that being blue or round is not important to Company X, but the functionality of the widget is important.

Projects proceed with some balance between clarity and ambiguity. It is important to understand this and identify prior to the start what balance is needed. How complex is the widget? How much detail is needed regarding the widget?

  • Higher Complexity = Higher Cost
  • Higher Detail = Higher Cost

Specifications around the widget, what is being bought, is a balance between clarity and ambiguity. When a project is starting it is important to have an understanding that there is a level of clarity which is needed and a level of ambiguity which is tolerable. Change in a project is inevitable. However, change has a cost.

What if the software company with the lowest bid makes a blue colored round widget, but does not get the functionality correct? Because the needed functionality is not present, a change is required. Changes cost money. This cost is both the cost to make the change in functionality and the loss due to the widget not being available. It is quite possible that the cost of the change now makes the company with the lowest bid the highest cost.

There are other considerations as well such as how something is built, future maintenance, ease of adding functionality. The lowest cost at first glance, does not mean it is always the best choice

Ways to Add Clarity
(A.K.A. Best Practices, Recommendations, Things to Try, Solutions)

1. Visible to All

There is a cost to both clarity and ambiguity. Documentation which can clarify a widget takes time and effort which has a cost. A lack of documentation which adds ambiguity around a widget adds to the possibility that rework and change will be needed before the widget is completed. I recommend the Rapid JAD principle of Visible to All as a model for gathering data about a widget and adding clarity. This can include pictures, diagrams, and flows. Imagine if the customer had provided a picture of the swing they wanted.

2. Six Components of a Well Written Requirement

Often requirements which are developed are missing information which helps add clarity. In my blog The Magic 6 I list the six components which should be a part of every requirement.

3. Test First

Whenever possible, provide the test(s) for successful completion of the widget along with the requirement detailing the widget. Providing the test(s) adds clarity to what the widget must do. For example, the swing may have weight requirements. Specify that you will be testing it with 150 pounds of weight.

4. Dictionary of terms

Different companies use terminology differently. This can lead to confusion. If there are terms you know are used in a specific way in the company, define them. I was in a meeting and the presenter was using the term, “Impressions.” I was wondering if the audience knew the definition of an impression. If they did, perhaps they would not have been as impressed.

Summary

Projects can have a lot of additional costs. For high cost projects or projects which are business critical, I always recommend looking at the past experience of the leaders who will be running the project on a day to day basis. They will know what to look for to balance clarity with ambiguity and make sure clarity is pulled in where there is currently ambiguity. Experience will help get you the needed widget in a timely fashion. After all, if what you need is a tire swing, but it costs you like a La-Z-Boy recliner or takes as long as a coaster, someone may be looking for the noose.

 

Facebooktwittergoogle_plusredditpinterestlinkedinmail
Categories
Rapid JAD Time Management

Bending the Dimension of Time for Quality

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Bending Time in the Quality Triangle

So much to do. So little time. If only we had more time. Have you felt this way about a project?

One colleague of mine likes to say, “Time, money, or resources. Which one do you want to sacrifice?” This is another play on the Project Management Triangle of Quality.

Time x Resources = Scope

If your time is fixed, then the only way to increase scope is to increase resources.

If your resources are fixed, then the only way to reduce time and still get the same scope is to sacrifice quality; or maybe not…

Bending Time

What if you can bend the dimension of time? Get more stuff in the same time, all the while increasing quality. This is in effect increasing scope without increasing time or resources.  This is the proven method we implement and what you can put in practice through the implementation of Rapid JAD.

Expand time. Expand the possible.

Facebooktwittergoogle_plusredditpinterestlinkedinmail
Categories
Document Management Rapid JAD Requirements Software Development

Blow Your Mind Requirements For Results

Facebooktwittergoogle_plusredditpinterestlinkedinmail

The Magic 6 is a black ball with the number 6 on it

Six components of a well-written requirement are so powerful that I call them magical. Missing any one of these six requirement attributes will cost your project.

Capture them up front to save money, time, help communication, and minimize frustration. Have you hired a company to gather requirements? They should provide these six.

Because I love practical examples and keeping it simple I will provide a short explanation with a real life example. This example comes from a centralized system that tracks issues for a company with multiple locations.  

1. A Unique ID

This is the first attribute of a good requirement. In addition to being unique, the identifier for each requirement should capture an area or grouping as well as a count. The grouping communicates the area within the entire project and provides context. For a system that tracks and communicates issues, a View Updates group was created. The unique identifier, uses an abbreviation and a numeric. For this group I used VU.01 for the first requirement in the group View Updates.

2. Identification of who needs the requirement

This is typically a group name, such as Customer. This communicates the group needing the feature, which provides use context as well as an idea of security level. This system has customers who need to view issues affecting their multiple locations.

3. Statement of what is required

A statement of what is required identifies the task to be accomplished or the action to be performed. For customers with multiple locations, “Search by location is needed for issues.” This communicates an action a customer needs to take.

4. Statement of why the requirement is needed

The market for a product as well as competitor products can be the impetus for rapidly changing a requirement. Communicating why something is required also provides information on when it may no longer be needed. For issue tracking, search by a specific location is needed so that the customer can see all issues affecting a location.

5. Acceptance Criteria

Ideally acceptance criteria is communicated by a business owner. This provides clear communication to the development team when the business will agree that work on a requirement is fulfilled. When a customer can search by a specific location and all results are displayed, this requirement is complete. For more information on this topic, see The End Goal – Removing Ambiguity in Requirement

6. Business Owner

This identifies the person who can answer questions regarding a specific requirement, Matt Murdock. All requirements should have a point of contact in the business. It can be months after a requirement has been captured and development questions arise. In addition to clarification, there may be impacts from other events that come along and you will need to get input the right person in the business. 

Blow Your Mind

If you are looking at a requirements document and the Business Analyst captured all six of these attributes, that should blow your mind. Take them to lunch and thank them, they are going to save your project time and money.

Facebooktwittergoogle_plusredditpinterestlinkedinmail
Categories
Change Management Content Management Document Management Engagement Management Rapid JAD

How to Synthesize the Business Analysis Competencies

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Business Analysis Competency

Rapid JAD provides a practical solution for how a Business Analyst can quickly master the organization and synthesizing of large amounts of information provided by stakeholders.

When you look over the IIBA Business Analysis Competency Model there are a large number of competencies and tasks. Below is one pair from each major section which brings home the point that one needs good practical processes.

1.  Category – Business Analysis Planning and Monitoring

Task: Plan Requirements Management Process
Competency: Identifies and communicates risks and issues that may require changes to plan or scope

2.  Category – Elicitation

Task: Document Elicitation Results
Competency: Captures information provided in elicitation sessions

3.  Category – Requirements Management and Communication

Task: Maintain Requirement for Reuse
Competency: Organizes and maintains requirements for reuse

4.  Category: Enterprise Analysis

Task: Defines Business Need
Competency: Identifies and defines business needs

5.  Category – Requirements Analysis

Task: Organize Requirements
Competency: Organizes and Synthesizes large amounts of information provided by stakeholders

6.  Category – Solution Assessment and Validation

Task: Allocate Requirements
Competency: Allocates stakeholder and solution requirements among solution components to maximize business value

Just the six above can seem overwhelming, let alone the entire competency model!  And while the competencies are defined, how one becomes proficient or implements a task is not. This is because businesses and jobs in Business Analysis can vary greatly.

This is why we have developed the Rapid JAD principles, to provide practical methods, which when followed, will push aside many of the pitfalls a Business Analyst can run into while performing their tasks and mastering their competencies.

The Rapid JAD team has years of practical experience in government, nonprofit, and private sectors in numerous industries. We would love to hear from you. Let us know what your experience has been as you implement the principles and master the world of Business Analysis competencies.

Facebooktwittergoogle_plusredditpinterestlinkedinmail
Categories
Uncategorized

How to Increase Your Shares and Click-Through

Facebooktwittergoogle_plusredditpinterestlinkedinmail

How to increase your shares and click through. An example of CoSchedule's Headline Analyzer

Building quality content and creating consumer appeal to reach your target market takes a new mindset. These five takeaways help in a world of social marketing: Topic, Title, Graphic, Lead Paragraph, and Content.

As Erik Jul points out in I Don’t Like to Write, it is fun having written! But even if you have written, it is no good having a site nobody visits. This post is a follow-on to, Increase Traffic to Your Website and Love the Results, because I am passionate about marketing, social, and the web.

The Topic

  1. Topic: This is the first thing to identify. What do people want to read? Want to know about? Want to Share? And most importantly which of the above answers is a topic you want to write about? Writing is always better when you like and want to write about a topic. With these questions answered you have a topic.

The Social Post

The next three items are new and go together because they are picked up by social sites when posting a URL. On social sites, people will share, re-post, and re-tweet regardless of content. They do this because they like what is communicated in the post itself. This might not have been as important in the past, but times they are a changin.

  1. Title: When creating a title, ask yourself, is it a good title? Is the title catchy? Is the title shareable? Additionally, you can now rate your Title on CoSchedule’s Headline Analyzer, to get another thought on the value of your title. Let’s look at rating from a recent popular in your network list from Twitter.
  2. Graphic: All posts, topics, or web pages need a good graphic. Create a graphic which is related to your topic and one which is interesting. Ask yourself, is it catchy? Is it shareable? Whenever I am out and about I take pictures. Pictures of all kinds of items. Now I have these available to use. And do not forget Memes, graphics with text on top, as people love to share memes.
  3. Lead Paragraph: The first paragraph is picked up by social sites when you provide the page URL. This paragraph, in conjunction with the Title and Graphic may be the only thing people read as they may not follow the link to your content. Make your lead paragraph something people will want to share all on its own. Convey the worthiness and message summary of your topic in the lead paragraph.

And Then There is Content

  1. Content: This has been important for the past decade as a way to increase page rank on search engines. People do want good content. If you desire people to come back to your site, good content is a must.
Facebooktwittergoogle_plusredditpinterestlinkedinmail
Categories
Rapid JAD Software Development

How to Take the Stress Out of Large Software Projects

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Momma singing me to sleep

I remember those ol’ days when I was stressed out about software projects. Not at all like momma singing me to sleep.

220 requirements, 14 design sessions, and 7 months into the project and my mind is jumbling bits and pieces together. The project manager asks me a question. I know some of the topic. I know this was discussed. Others made decisions.

Then I am thinking, why is anyone wondering about this? What is in scope or out of scope? Ah, we have a new project manager and this was a project manager number one discussion topic.

Thankfully I work on a team that implements the Rapid JAD principles:

  • Capture Now: If this was used, then we captured the topic and important decisions
  • Document Once: If this was used, then we have accurate notes stored in our document repository
  • Visible to All: If this was used, then everyone can find the information
  • Revise Quickly: If this was used, then the information is current

Finding that tidbit of information is a document repository search away…found. Ah, now I see an issue was created and logged in TFS…there it is.

Rapid JAD principles take the stress out of large software development project. They are as comforting as momma singing me to sleep.

Yes, I remember those ol’ days when I was stressed out.

Facebooktwittergoogle_plusredditpinterestlinkedinmail
Categories
Requirements Software Development

The End Goal – Removing Ambiguity in Requirements

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Clarity

When you are done reading this post the importance of knowing the end goal will have been communicated:

• Definition of Done
• Acceptance Criteria
• What does success look like?
• What happens?
• What gets completed?
• What is the result?
• The end goal

These bullets all represent one concept. As a systems developer, I want to know up front what is expected of the system when I am done developing what was requested. What am I to deliver?

I can read what a requirement states, but do I understand what is to be accomplished by the requirement? What is the purpose? The goal? The reason this requirement lives?

This is a critical piece that is often missed when requirements for system development are captured. Without this piece it is difficult to measure success. Let’s look at an example.

User Story
As a Customer I want to follow “issues” of interest as a priority so that I can focus on important issues as a priority.

This User Story is clearly written. I can read it. I understand all of the words. Yet, this is still vague. How should this be developed? What is result? What happens? It would be nice to have an answer to these questions from the person who wrote this User Story. Something such as the Acceptance Criteria, which when met, the person who wrote the User Story could say, “Hey it is working. It did what I was wanting.”

Something such as the following takes only a minute to capture, but adds a wealth of clarity to the User Story

Acceptance Criteria
I can hit a “button” and that issue automatically goes to the top of my view queue.

Without the clarity of the end goal, the Acceptance Criteria, development could go in any number of directions. By adding Acceptance Criteria, to User Stories or Requirements, the desire of the person who wrote the user story is clarified and it provides a measurement for the completeness or success of the delivered product.

Facebooktwittergoogle_plusredditpinterestlinkedinmail
Categories
Content Management

Increase Traffic to Your Website and Love the Results (7 principles you need to know)

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Search Rank Increasing

Do you want more visitors to your website? You can spend a lot time and money writing and creating content, but:

  • What good is a website which nobody sees?
  • What good is a website visited by school children when the people you want to attract are busy mothers?
  • What good is a website which does not enhance company objectives?

Writing with purpose is the trick to increasing organic search engine rankings.

High search rankings. More people visiting your website. These are things that will make you love writing.

Below are the seven basics you need to have down as you write content for your web page.

  1. Page Content

As content is written and created these three things should be kept in mind:

  • Target Audience
  • Purpose of the Content
  • Key Messages

If your company has not yet identified these three items, make this a high priority. Print these out and have them available as your write the content for your page.

  1. Search Strings

Identify two likely search strings that someone from your Target Audience will enter into a search engine when they are looking for the content on you are writing. This needs to be answered prior to writing/creating the final page copy. The answer to this section directs content for the rest of the page.

  1. Titles

Brainstorm by writing down your ideas, then mark the one you want to go with. This will allow you to look back a later time and see the ideas you had. The first part of the page Title displays in the browser tab. This helps a user who has multiple tabs open to identify the one they want.  Additionally, the title should contain words from the Search Strings you identified if not the entire string itself.

We recommend using a Headline Analyzer such as the one at CoSchedule,  http://coschedule.com/headline-analyzer

  1. Descriptions

Descriptions are often used as part of the search results page from a search engine. Description tells the user what is on the page and why they want to follow this search result link. Text in the description should contain words from the Search Strings you identified if not the entire string itself.

Description is placed in a meta tag on your page. You can see this on most web pages by looking at the page source and searching on “description.”

  1. Content

In addition to communicating to the Target Audience the Purpose of the Content and Key Messages, the content should also use words from the Search Strings as appropriate. Do not sacrifice good content by repeating words from the Search Strings, but where appropriate make use of those words rather than other synonyms. And of course you want content that is useful to your Target Audience. Content they want. Content they want to come back again to see. Content they want to Bookmark or add to their Favorites.

  1. Content Headings

As you write content for the page, content headings should contain words from the Search Strings if not the entire string itself. In Microsoft Word headings are available as a selection: Heading 1, Heading2, etc….

Typically, the main heading is the first thing you see in the page content area.  Sub-headings are topics related to the heading, breaking the heading into parts. Below is an example for protective dogs.

Protective Dogs for Your Family (Heading 1)

Doberman Pinscher (Heading 2)

The Doberman Pinscher, or Dobermann, or Doberman, is a medium-large breed of domestic dog of the mixed-breed category originally developed around 1890 by Karl Friedrich Louis Dobermann, a tax collector from Germany. Wikipedia

German Shephard (Heading 2)

The German Shepherd is a breed of medium to large-sized working dog that originated in Germany. The breed’s officially recognized name is German Shepherd Dog in the English language, sometimes abbreviated … Wikipedia

  1. Picture Alt Text

For each picture on your page describe in a sentence or two what the picture is about. Descriptive words that tie the picture to the page Content are needed and if you also make use of words in the Search String, that is a bonus.

Summary

Following these seven principles will increase your page ranking. If you are improving an old page, then be sure to capture the current search ranking. Then, 60 days after you have modified your page using the 7 principles above see how the ranking has changed. As more visitors are able to find your page you are sure to love the results.

Facebooktwittergoogle_plusredditpinterestlinkedinmail
Categories
Software Development

Tee Up! How Building Software is Like Playing Golf

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Golf Course

The Course Layout

We have a course laid out and we are moving along the course. Not all courses are the same, but they have the same basic structure and flow as we play:

  • Tee off on hole 1
  • Move along the fairway
  • Hit onto the green
  • Sink the putt
  • Move on to the next hole and repeat

The golf course structure aids us by its layout and keeps us moving along in the proper direction doing things sequentially. Similarly software development methodologies have a structure which keeps development moving in the proper direction with a repeating sequence.

Playing the Par 4 Hole

For a par 4 hole, the plan prior to tee off is to drive onto the fairway. Put the second shot on the green. One putt for birdie.

However, things do not always go according to plan. We may hook or slice a shot, hit the rough, a sand trap, land in the water, and even a hit out of bounds is possible.

This is when the golf course structure pays off in that you can be moving along the fairway toward the green even though you are not necessarily in the fairway. There are rules to follow, you have the direction to head, and you know the goal.

Similarly as a golf course is broken into 18 holes, software development is broken into pieces, often referred to as an iteration. And while you have a plan at the start of each iteration things do not always go according to plan. However, with the structure of your chosen software  development methodology in place you know the direction to head, have rules to follow, and you know the goal of the iteration.

Summary

For many finishing with a 72 after 18 holes is the goal, but one which is not often reached. Still, you have a goal before the game starts and from experience you realize that many things can come up as you play.

Software development is similar, in that you can plan out everything you want to do for the entire 18 holes before you step up to tee off on hole one, but there are many things that happen along the way to finishing.

Understand that golf is like software development. It is likely not going to go as planned prior to tee off. Do not get shaken when you hit a sand trap or other obstacle. Pull the right club and play on.

With a good software development methodology in place you will recover when things do not go as planned. Expect things can happen up front and smile big when things go as planned!

Scramble anyone?

Facebooktwittergoogle_plusredditpinterestlinkedinmail
Categories
Requirements

TV Dinner Requirements

Facebooktwittergoogle_plusredditpinterestlinkedinmail

TV Dinner Requirements

TV Dinner Requirement have the following characteristics

  • Conveniently pre-packaged
  • Tasty like cardboard
  • Surprising when there is something good inside

Already Packaged

TV Dinner Requirements come to you already packaged and ready to go. A business has hired an analyst to define their requirements and package them up in a document. The company then puts their TV Dinner Requirements out for other companies to bid for the work, sometimes called a Request For Proposal (RFP)

If you find yourself working with TV Dinner Requirements, then you are beyond the defining of requirements typical of Classic JAD and are on to the next phase:

  • Validation of requirements
  • High Level Design

Remove the Plastic and Heat

Pull off the plastic wrap and validate the requirements. They may have become stale sitting around in a frozen package as time goes past.  How old are these requirements? Have they become stale like cardboard? Are there any good requirements in the package? Can someone in the business tell you why the requirement is in the package? Often the reason something is in the package is unknown! For these reasons a good business analyst will validate the requirements in the package.

Things should heat up as you share the TV Dinner Requirements with business leaders and developers and put together high level designs as a proof of concept. Everyone will like talking about the good stuff they find inside as well as the bad stuff.

Keep in mind that TV Dinner Requirements can be fast and easy, not necessarily good.

Facebooktwittergoogle_plusredditpinterestlinkedinmail