Unauthorized use and/or duplication of this material without express and written permission from this blog’s author and/or owner is strictly prohibited. Excerpts and links may be used, provided that full and clear credit is given to John D Carmack and Random Acts of IT Project Management with appropriate and specific direction to the original content.

Tech

Posts Tagged ‘business analysis’

After a round of LinkedIn discussions about project failure, it was a general consensus that most project failures stem from bad or vague requirements. This is a recurring theme in project management, it seems. Well, in “Eight Things Your Business Analysts Need to Know”, it appears that Brad Egeland would agree:

In an online poll of 2,000 business professionals, the question was asked, “What are the key challenges in translating user needs into system specifications for mission critical projects?”50% stated poor requirements definition as the key challenge.Inadequate risk management (17%), poor scope control (15%), and communication problems (14%) followed far behind as key challenges.

After the discussion online, someone posed the question to me, “Who should gather the requirements?” Again, Egeland’s article answers the question, “What about the business analysts? What role do they play?”

Egeland’s article, which distills down a whitepaper from Gantthead, goes on to identify 8 competency areas for BAs.

But, you know, input from a BA is usually not hard to get on a decent-sized project. On smaller projects, though, it can be difficult to even get a BA assigned. So, now what? Well, it usually falls to the project manager if a project falls under a certain number of hours. Therefore, it would behoove any decent PM to check out these competency areas as well, especially the first 5. Don’t be afraid to pull in an architect or a SME to answer questions, either.

If you really want to rescue a project from the safety of victory and dash it into the jaws of defeat, though, then ignore competency #6 “End-User Support”. How many projects have I seen that were “done” but lived on as the walking dead that sucked the life out of team members long after it was put away?

OK, I’ll admit it: I am a fan of Seth Godin. I got introduced to Seth’s Blog through Small Business Trends (specifically Anita Campbell). Consider this a free endorsement, guys! I am not associated with either in any formal manner (but I know Anita from a previous company).

So, that’s why I have such high expectations of Seth’s books. My expectation of The Big Red Fez: How To Make Any Web Site Better was no different, and it did not disappoint! If you are in IT and have any say whatsoever in the user interface, especially on the web, drop everything and get this book! Now! If you are a front-end developer, get this book. If you are an IT manager overseeing software applications that run on the web, get this book. If you are a project manager overseeing web projects, get this book. If you are a QA engineer and test the front end, get this book. Oh, and did I say to get this book?

Compare the price of this book (under $10) to any user interface guide, and tell me what gives you the bigger bang for the buck!

Godin presents the material from the viewpoint of a user. We in IT need to face the fact that it is the enduser who is going to either validate or invalidate the interface. Unfortunately, some engineers forget that it is the enduser who either is going to use the thing or quit and do something else. If that enduser is internal, then you might have a captive audience, but you will also have a lot of trouble tickets and user frustration. If that enduser is a customer, they might just decide your competitor’s site is easier. Not only does Godin provide very practical advice, but he does so in a way that is humorous and engaging.

Godin starts off by telling us that engineer’s and marketers view user interfaces differently. He then will have us imagine a monkey in a red fez. You know, the kind that you see in the pictures of organ grinders and such. What motivates the monkey? Bananas. The monkey searches for the banana in the same manner that a user will search the web site for the payoff.

Before I get too far along, Godin isn’t looking down on people. He includes himself in this by saying “we” and “us”. He stresses the point that “we” are often too busy and “we” are distracted too much to really think very long about a web page. In fact, he later on tells us that the average person decides whether or not to stay on a particular web page in 3 seconds. Therefore, the banana must be so obvious that it sticks out on a web page in 3 seconds or less.

OK, let’s get the cons out of the way first. Or, should that be “con” singular? Godin puts in a lot of screenshots, thankfully. However, be sure to have your reading glasses on! I was reading it with my lower powered glasses, and it was a bit of a struggle. Fortunately, the accompanying text pointed out the important bits.

Still, I have to admit that there were times when I was reading through the book and I was ready to exclaim “hallelujah!” Just about every pet peeve I’ve ever had with websites is in this book.

In more than one section, he points out that a lot of input screens ask for redundant information. In “If the Computer is so Smart, Why am I Doing All the Work?”, he asks why does it ask for a billing address when you’ve already given it a shipping address. Right across the page is one of my favorite pet peeves: You know the zip code, so why are you asking for the city and state? Let me add one even further, because I’ve seen some horrendous ones lately that ask for country, state, region of state and nearest municipality, all with the zip code and city already input!!!!! I can understand why Godin says that 60% of all online shopping carts are abandoned just before checkout. I know I’ve done it.

OK, another pet peeve I have with about half of existing software is the handling of error states. They are not graceful, they are usually uninformative and they are sometimes downright cryptic. Godin’s perception on these is that on the web it is even worse because many error pages do not give any rewards for reporting the error, no way to contact someone about the error and no incentive for even trying again. In other words, companies are just begging you to go visit the competition through frustration.

Oh, yeah. Ever been in cubicle and need to check out something online, only to go to the site and have it blare out loud music? What about going to a website and have it play some dumb movie when all you want is to check on the price of an item?

The point is, you don’t want to lose a potential customer in a maze of unrelated activities that not only frustrate them but cause them to become either frustrated and quit or think less of your company or IT as a result. Decide what the goal should be and put the banana in an obvious place to lead them there. Make it simple to view and simple to use. Imagine how much easier tech support would be if everyone did this!

I’m going to repeat my mantra here: Internal users are internal customers. If internal customers get frustrated, then IT gets a bad rep. That affects everyone in IT eventually.

The book covers much, much more, but one point that project managers can relate to is measure the changes. You don’t know if you are improving or not unless you measure.

Once again, even though Godin writes from a “marketing” point of view, he hits a homerun with IT management concerns as well. Go to his site, go to the link at the top of this review or go to the library, but read this book!