Last minute changes – documentation approach Waterfall project

You are not working in an Agile environment but instead the old waterfall when someone realizes an approach is no longer going to work making parts of what you have documented no longer valid.

Before you rush off and change the documentation, you have to consider the 3 elements of a project:

1 – Quality

2 – Cost

3 – Time

Always remember that if you try to satisfy all 3 elements, you will fail. Below are the approaches to take based on the top element of the project:

Quality Project:

  • Documentation should be changed to match the detail of change. Even though everybody understands it at the time and some people may suggest a note of the change would be enough, in a few months people will complain about the confusion in the document and the note approach runs the risk that the wrong item is implemented.

Cost

  • Cost is a difficult one in that it affects quality and time. Usually however the cost of the change in negotiated at the time it is realized, meaning that more money is found or something is removed from the project to save costs. In this case it may be possible to pass on the work to a more junior person (cheaper) – I have even seen High School kids hired to do the work if the rules of the change are simple enough. Of course at the end of the day, the Time approach may be the solution,

Time

  • What is the absolute minimum way to document the change that everybody agrees on. Agreement must be reached by all parties that read the document.

So the next time you have a change, think about the approach if one has not already been established.

Business Analysts are catalysts to success

People outside of IT often wonder what a Business Analyst does and that includes our business partners who we work with. Their is great concern that we do not provide “Value Add” services.

 in the BA times recently wrote an article about BA’s thinking of themselves as bridges and how that is wrong.

I have seen the bridge thinking BA’s in action, and they are no more than note takers and usually midway through a project nobody is happy with the results.

As Business Analysts, we are there to act as one of the catalysts that make the project successful. However that does not mean a BA that does well in one project will do well in another if they do not have the skills.

If you look at the job search engines you will see that BA skills required for roles can vary from company to company and department to department.

Examples:

  • Data Warehousing BA’s are expected to understand database structures and know SQL.
  • Business intelligence BA’s can need some of the skills of the Data Warehousing BA along with reporting tools and statistics.
  • Front end BA’s are expected to understand UI/UX, use cases.
  • BA’s that specialize in Business Process are expected to understand the business they are working with.

What we can see from the desired experience is that companies want a BA that can mentor and guide. Having the ability to just gather requirements is not enough. There is an expectation that a BA will bring knowledge and experience to the table along with other soft skills such as negotiation.

It should be noted though, that some companies are not prepared to let the BA mentor them because of their thought of the BA being just a bridge between IT and Business. It is up to the Business Analyst to break down this stereotype to make them realize the “Value Add” that a BA can bring to the table.

ui – Tactile feedback – Why BA’s need to consider cost of failure without it.

In this article I want to ask Business Analysts to consider risk cost calculations when it comes to UI that reduces or removes Tactile Feedback from a user interface.

I like to share examples of User Interfaces that seemed good in the lab but not in reality.

In the book  Yeager by General Chuck Yeager / Leo Janos,  the pilot Chuck Yeager makes reference to the one time the F16 airplane had a “Fixed Force” sidearm control. Basically a control stick that did not move but relied on the amount of force the user applied to it to determine what the controls would do.

It was not a success as the lack of tactile feedback made it difficult for the user to know how much force they were applying. In his case, they replaced the fixed with a moveable stick that could move about an inch in two directions.

Even then, moving of a stick by itself may not be enough as witnessed by the crash Air France Flight 447 on June 1st 2009. The article link below explains how lack of Tactile feedback may have led to the crash of the flight. In the article it is suggested that since the co pilot could not see or feel what the other pilot was doing (they were using a sidearm control) he was unable in time to rectify the situation.

http://www.telegraph.co.uk/technology/9231855/Air-France-Flight-447-Damn-it-were-going-to-crash.html

With the advent of more touch screens devices, we are bringing the lack of tactile feedback to the masses. Certainly we can feel a swipe of the screen but when it comes to pressing something, we have no clue by our touch that the event took place. Even with the swipe, it is possible that the screen was dirty and thus did not register our swipe. In not all cases will it be possible to follow our hand / finger movements with a glance by our eyes thus making the Tactile feedback more critical in those situations. We could add sound to each contact but then that can lead to over abundance of sounds which in themselves become a distraction from the task. Military pilots in various recent wars have complained about having cockpits full of various informational sounds all at one time that if they can turn them off they do. This act of silencing the sounds nullifying the benefit the sound was meant to serve.

While we can see the advantage of the flexibility of the touch screen in that we can change the controls displayed to match the task at hand, the risk of the task needs to be considered. As Business Analysts helping business introduce new technology, we must make sure that the risk of limited or no tactile feedback is calculated against the cost if something goes wrong. This information will help fund the UI/UX department in their quest for the best/affordable UI interface for the situation.

 

How fake UX/UI experts impact your Project and Profits

General process for IT visual design in Technology. Web, Mobile, Tablet, Smartphone, UX and UI experience.

General process for IT visual design in Technology. Web, Mobile, Tablet, Smartphone, UX and UI experience.

Why, I question am I still seeing issues with Visual Design projects that affect Web, Tablets and Mobile applications? After all the years we have been doing this, it seems that important steps are getting lost in the mix. The end result is a partial or failed implementation or a project that runs on longer than anyone thought it would.

20 years ago, a company may have been forgiven for issues with their customer facing web site but now that everybody has been doing this for a while, forgiveness is in short supply. You either get it right or face a backlash.

We have learnt that with the ability to quickly present a screen to a large audience there must be some thought as to how well it will be received. Companies have expanded their development groups to include the following roles to improved UX/UI:

  • HCI expert – a person or group of people that look at how the company web site or mobile application will be used and determine the best way to design it from a usability perspective.
  • Graphic Artist (GA) – takes the finding of the HCI expert and produces rich mockups that mimic the end result. In some cases they GA may even provide the actual production code.

Why then are Visual Design projects facing issues? These issues then lead to rework that puts more pressure on the rest of the team to make up the shortfall in quality. For a Business Analyst / Product Owner, this means less time to be working on the next project as they get stuck picking up the pieces of the current one. Budgets are also blown as the project extends its timeline limiting funds that could have been used for more new development.

My experience is that people and companies are claiming they are UX/UI experts but really they are not. They don’t know anything about personas; how to communicate design, how visual design projects work. I am sure they don’t know many other things about UX/UI but the former items are what I will focus on.

PERSONAS

A company needs to know who they are reaching out to with their Visuals on the internet. Personas affects how a user will interact. Some personas may be more computer literate than other. Studies need to be done to determine what works and what does not from a design perspective.

COMMUNICATING DESIGN

This is big one. Anyone can make  a pretty picture of what a screen should look like but can they explain all the possible user interactions that can happen in a way that development and/or graphic designer can understand and implement. Ambiguity here leads to either a failed implementation because of wrong interpretation or delayed implementation as questions on design are resolved. Those delays can lead to the project doubling in length.

VISUAL DESIGN PROJECTS

Many components go into a Visual Design project. On the one hand we have the screen interactions and on the other hand we have the technology to be used. A UX/UI team that silo’s itself from the rest of the project team ends up creating work that may not be applicable to the group. Examples: developing a solution for Android devices when the company plans to only support Apple devices or a Web design company that you hire to work on Mobile Applications.

 

I could go on for several days on the subject of UX/UI impacting project but I wanted to keep this article as a  light weight discussion on how fake UX/UI experts impact projects.

To leave you on a good note, here are some suggestions on how to Identify the fake UX/UI experts:

  1. Request examples of their persona studies. Get them to justify the personas and what they learned. Ask them if they know what 508 compliance is.
  2. Request examples of their design documentation that shows wireframes/mockups and put your developer hat on and see if you can find any ambiguity in what is presented.
  3. Ask what technology they have worked with and see if it ties in with what your company is doing. Too many companies don’t see the difference Technology brings so they assume that because they had success with the Web they can easily do Mobile Applications.

To get a good understanding of UX/UI, I recommend reading the articles presented  by the Nielsen Norman Group.