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 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,


  • 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.


  • 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.

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.


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.


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.


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.


Starbucks Coffee – Two lessons on Business Analysis post Proof of Concept

I was reading Howard Schultz /  Dori Jones Yang book – Pour Your Heart Into It (1997 Hyperion)- when I saw two examples on how missing items during the analysis phase can impact you later.

1 – United Airlines – Coffee. In January 1996, United Airlines started serving Starbucks coffee. United and Starbucks knew that the brewing equipment needed upgraded but not all of the equipment was in place by day one as the equipment supplier could not produce the parts needed by the deadline. It took four months to fix. As Business Analysts we have to consider the impact and risk of a proposed solution to the timeline of the project and raise alarm bells should there be a concern of the solution not being in place on time.

2 – Eggnog flavored syrup. In 1994 a decision was made to save money and speed up handling of Eggnog flavored coffee by using a syrup instead of a carton of eggnog. Proof of concept and quality control was not properly done leading to an implementation that backfired. The end result was a return back to the process of using the eggnog cartons the following year. When working on a solution that is fundamentally changing the product that is sold, great care must be taken by the Business Analyst to:

  • A – Ensure that the proof of concept guarantees that the new product is equal or better than the old in a measurable way.
  • B – Final implementation plan does not cause the quality of the new product to deteriorate below what was shown at the proof of concept.

Business Analysts need to be able to think beyond the obvious to identify the risks and problems that can crop up. There is a tendency to get caught up in the moment by short term success and lose sight of the greater picture.

In both cases above, the team failed to see beyond the initial proof of concept the pits in the road that would cause them trouble.

Where Senior BA’s end up

I am actually going to take it easy this week and refer you to an article written by someone else.

This article is good reading if you are considering a career as a Business Analyst or are at the more junior end for it lets you know what the 10 year career path is.

After reading it, you may want to reflect and consider where you would like to end up and steer your ship in that direction.

What is the future for Senior Business Analysts

Happy reading

UI Designers need to understand limits of Project Team

Back to my football analogy again.

In this case we have a Quarter Back calling his dream plays but not taking into consideration the qualities or experience of his team.

So what am I getting at here?

Imagine you are working on a Customer Facing application and you call in a User Interface company (the Quarterback) to design the Front End and it’s their first time working with the Development team (rest of the players). Quarterback keeps throwing the ball but nobody is catching it because they don’t know the plays or signals.

It is important for the success of a project that the team gets onboard to understand each others strengths and weaknesses early on in the lifecycle of a project. If this team relationship is postponed till later then everybody ends up playing catch up as they try to resolve the issues. In Football terms, this means the opposition wipes the mat with them.

So imagine if your UI designer is designing screens that the Development Team is not comfortable to implement for various reasons – stability, development effort etc. It is better for the sake of the project that the UI designer knows and understands what he has to work with so that efficiency in design can be achieved.

Some of you will argue that the Development team should work to the level of the UI designer because his word is the rule. Unfortunately that approach is short sighted. We don’t live in a perfect world and at the end of the day there needs to be a little give and take between both sides. A team full of individual stars usually does not win a game over a mediocre team that plays well together.

Certainly a badly designed site will fail but most UI needs can be met with various solutions and the UI designer needs to be flexible to understand which solution can be implemented within the constraints of the project.

Some may ask how all of the above affects the Business Analyst. In simple terms, the amount of rework required to manage the changes Development bring about leads to inefficient use of the Business Analyst as they continue to rework their documents to meet the new design.

« Previous Page