No bones about it – Lord Sugar needs a business analyst

Following controversy in this week’s episode of The Apprentice, Rob Dinsey makes the case for a Business Analyst in the boardroom.

Like many of you, I continue to watch BBC One’s The Apprentice, even though it seems less related to anything like real business with each season that passes. Last night’s episode was an exception however: the task for each team was to purchase nine items for the lowest possible price. What transpired was one of the most controversial events in the show’s history (if we exclude releasing Katie Hopkins into the wild) and one of the clearest arguments for the value of a Business Analyst that I’ve ever seen.

For those who didn’t watch the show, Colombian lawyer Felipe Alviar-Baquero came under fire after purchasing an assemble-at-home paper skeleton, instead of the ready-assembled, standing, plastic version purchased by the opposition team for a much higher sum. Lord Sugar objected to Felipe’s decision and it cost the latter his place in the process. Within minutes, the hashtags #skeletongate and #justiceforfelipe were trending on Twitter, while public sentiment on The Apprentice: You’re Fired was very much against the show’s self-styled judge, jury and executioner.

The crux of the problem lay in the requirements sheet given to the candidates which, as far as the viewers could see, said only:

“HUMAN SKELETON Specifications: Full-Sized Anatomical Skeleton. Minimum 150cm tall.”

Felipe’s papery person fulfilled those requirements to the letter, but the end result was extreme customer dissatisfaction. How could this happen?

As a Business Analyst, gathering, writing and validating clear and comprehensive requirements is a key part of what I and my colleagues do on a daily basis. This is such a clear example of the importance of what we do that I want this episode to be shown in the training provided to new joiners of IPL’s Business Analysis Academy. The British Computer Society (BCS) lists the potential problems with requirements as including(1):

• Lack of relevance to the objectives of the project
• Lack of clarity in the wording
• Ambiguity
• Duplication
• Conflicts between requirements
• Omitting requirements

It’s questionable whether the problem here was caused by omitting a requirement (that the skeleton be both assembled and made of a specific material) or ambiguity in not including that information as part of the specification. It is, however, clear that the requirements given to the team were not complete, and the resulting offending purchase not unforeseeable. Deliberately or not, unclear requirements were given to the teams, ultimately leading to a good candidate losing his place in the process.

In a real project, poorly defined requirements can be even more costly. According to the BCS, over 80% of errors on information systems (IS) projects are introduced at the requirements analysis stage, compared to less than 10% during the actual development(2). Reducing and eliminating errors at the analysis stage should be a priority for all IS projects. A clear, concise and comprehensive requirement is much more likely to be developed correctly, able to be comprehensively tested and lead to a satisfied customer at the end of a project.

You could argue in this case that Felipe (and his complicit project manager Daniel) should have verified the requirements and the business need they were fulfilling with their author, but, like many delivery teams, they were under extreme time and cost pressures and this seemed like a sensible way to meet the requirements as written.

If only Lord Sugar had hired a Business Analyst, #skeletongate could have been avoided.