American Gods

My night time reading in the last few weeks has been spent on "American Gods" by Neil Gaiman. I must admit I have mixed feelings about this book.

Soon after the book was first published in 2001 it received several awards. I chose to read "American Gods" encouraged by its many readers' positive comments and pretty high score in Amazon's website. Before I purchased it I noticed a comment that stated this was a book readers either loved or hated, but I disregarded the warning thinking the probability of liking it was higher than not.

Well, to be honest, after reading it all the way through I can say I started to like the book only after I had covered about 80% of it. I guess it was only then that I started to understand the plot, somehow, to see its meaning, some of its purpose. "American Gods" is a book that kept me wandering "what's Shadow - the main character - doing?", "why him?", "what's the purpose of the many characters he finds through his journey?". I was on the brink of putting the book down for many a good days, but my curiosity - or my stubbornness - made me keep on reading.

Readers well versed in mythology surely appreciated Gaiman's choice of god characters, role and even their names. Surely this is part of the fun I missed.

The book is plagued with unusual characters and situations, it certainly seems to me an original story (but that is maybe because I have not read enough fantasy novels to compare with) and I think it is well written (but since English is not my first language this is not a qualified opinion). All in all, I struggle to understand what makes people call this book a "master piece", "best book ever" or "impossible to put down". Let's see what those enthusiastic fans say when the  announced TV Series sees the light

Lessons learned? Sure, but those I keep for me.

Validating Requirements

A large number of projects do not achieve their goals. Failure to properly validate requirements is one key reason why so many projects fail to succeed.

Gathering requirements is not an easy thing to do, it requires excellent interviewing skills, persistence and a fair amount of time. It also requires truly understanding the problem the project intends to solve, understanding what is needed and why is needed (in my personal opinion, the whys are too often not explored well enough).


Validating  requirements against project goals and objectives

Once we have the requirements projects need to implement a mechanism to effectively confirm that they are actually met. Validating requirements requires understanding:

• Business needs
• The problem being solved by the project
• The expected outcomes
• How the project is expected to solve the problem

In the IT area, Testing should be planned to validate this understanding, unfortunately this is not always the case. Sometimes, the testing planning team is not familiar enough with the Project Charter, with the business needs or the details of the problem being solved. Testing is typically oriented to validating requirements, but validating project goals and objectives is more than meeting requirements.


Techniques to validate requirements and measure project goals are met

There are some techniques that help us validate project goals and objectives:

• Use requirements traceability matrix: it is important to ensure every requirement points to at least one project objective and also make sure requirements are SMART (specific, measurable, achievable, realistic and time-bound)
• Develop methods for validating business requirements
• Include in the project budget the validation effort and the tools necessary for that
• Identify responsible individuals for measuring that project goals are met and that the problem has been solved

Validating meeting project goals and solving the business problem involves measurement beyond the project, part of the project work is building the tools and processes that ensure that validation can be successfully done. Tell me, have you ever worked in a project where you think  validating solving the business problem has been missed?

Intro to Analytics

In every industry, organizations are generating massive amounts of information. New technologies collect data better, faster and cheaper than ever before. Now, the question is how to obtain value from that information, value that help organizations become more profitable and productive

There are four types of business analytics capabilities that help us address different questions:

• Descriptive: What happened?
• Diagnostic: Why did it happen?
• Predictive: What is likely to happen?
• Prescriptive: What should I do about it?

Knowing what happened (reporting) and why it happened (diagnostic analytics) are no longer enough. Market leaders need to know what is happening now, but also what is likely to happen next and what actions they should take for optimal results.

Customers are being educated by e-commerce leaders like Amazon or user experience leaders like Apple and Google to expect a personalized experience in real time. As a result, customer expectations are rising quickly. Simply meeting these high expectations can be a major challenge for organizations that are not analytical.

Attracting and satisfying customers in a digital world requires significant investment in sophisticated big-data capabilities. It also requires connecting all your customer data and make sure that the data is high-quality; otherwise Analytics won't produce useful results. It may take time to collect enough high-quality data that can be used to create reliable predictive models.

Business analytics is about “anticipate and act”. Analytics is an "umbrella" term that encompasses data collection, statistics, data mining, predictive modeling, and decision sciences.

In the coming months I'm going to make it a priority for me to get further insight about this topic and I'll be sharing findings through this blog. Stay tuned!