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
Change Management Engagement Management Software Development

Avoid Project Management Pain

Facebooktwittergoogle_plusredditpinterestlinkedinmail

stingProject managers drive change. They sit at the helm of a chartered operation intended to deliver specified high-quality business benefits on time and within budget.

Project management is a noble and difficult endeavor—part science, part art—and effective practitioners must be skilled and experienced in a host of related disciplines too numerous to list here (but look here).

Various bodies of knowledge, certifications, and best practices arise and proliferate with increasing frequency intending to help increase the project manager’s likelihood of success.

Avoid Some Pain

Here’s the bad news: despite concerted and well-intentioned efforts, projects often fail to realize expected results. The perceived gap between delivery and expectation may prompt some project managers, sponsors, and would-be benefactors to consult the Schmidt Sting Pain Index for a scientific ranking of their pain.

Worse yet, much of that pain is avoidable. The key? Providing appropriate levels of organizational change management (OCM) to positively affect the people side of change.

Why? Because even the best IT project that meets quality, time, and budget objectives can still fail to deliver desired business results and return on investment by failing to address user adoption, utilization, and proficiency.

Prosci presents evidence gained through longitudinal surveys indicating that projects with excellent OCM are six times more likely to meet or exceed objectives than those with poor or no OCM (96% compared to 16%).

Brilliant! Because most IT projects implement solutions that must be adopted and used for business benefit, focusing on accelerating and improving user adoption, utilization, and proficiency makes sense.

In fact, not integrating OCM planning with project planning is like asking to be stung.

That’s what Schmidt did.

How integrated are your project and OCM plans?

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
Content Management Document Management Engagement Management Rapid JAD Time Management

Rapid JAD in Pictures

Facebooktwittergoogle_plusredditpinterestlinkedinmail

by Erik Jul*

capture-now
Capture Now. No time is better, and certainly not later.

document-once
Document once. Don’t do the work multiple times. Whose got the time?

visible-to-all
Visible to all. Everyone has to see. Why? They might have more perfect knowledge, opinions, suggestions, have approval authority, or just need a sense of comfort.

revise-quickly
Revise quickly. With all best efforts, you might get close to a final, correct, and complete artifact. But don’t count on it. Just change it as quickly as possible.

Rapid JAD really is simple. Execution is the key: decide (it starts with you), implement (start somewhere, but just start), adjust (learn as you go), practice (build the Rapid JAD habit), multiply (share the revolution and bring others along with you).

Facebooktwittergoogle_plusredditpinterestlinkedinmail