Why Projects Fail – The Early Indicators – Part 2

Building onto last month’s post of early indicators of failing projects. Including advice in the areas of:

  • Change Control
  • Stakeholder Management
  • Financial Management

This month I focus on the chunky topics of:

  • Requirements, Architecture & Data

Requirements

Some of the key points which could signify the project may fail are:

Many Enterprise Data Warehouse (EDW) & Business Intelligence (BI) projects fail because they take many years to gather requirements / do analysis / design, so that by the time anything is produced it is out of date.

Trying to nail down specifically what the BI requirements are (because these will change over time and, if you try and nail them down, they will be wrong by the time they are delivered), especially if it is a long project.  Best way around this is to plan phases of delivery or 3-4 months.  This will also demonstrate movement and success in the project keeping the project team and the business motivated in the project needs.

Business analysis and requirements documentation started too late, lack of good business analyst

Solution design and business requirements are not properly aligned.  It is key to first understand the needed of the solution, otherwise you will end up with the three different images on my image above with misunderstanding and wasted time/money.

Lack of certainty by the business on what they are trying to achieve – lack of clarity on requirements – lack of clarity on the data needed – project goes round in circles.  Happening with big data.  First you need to understand what the question to be answered is.  You cannot start with the data and expect it to generate a solution to a question that is unknown.

  • When the requirements are expressed as a multitude of existing reports/spreadsheets to be replicated
  • When the business analysts have to talk to the IT team without including the business to agree the way forward and the needs
  • When every requirement has to be signed off by many people. This can length the project phase significantly

When the business users fail to attend requirements workshops or unable to schedule workshops in user’s diaries, end up talking to IT surrogates and not understanding what the business needs.  The business must be fully engaged for successful delivery.

  • Requirements not signed off by the owner and development commences
  • No steering group for the project
  • Project metrics not defined / agreed / reported on

Architecture & Data

The lack of an enterprise conceptual data model to help understand;

  • What the operational data is representing
  • How to design the Enterprise Data Warehouse (EDW) – i.e. with the physical design representing the conceptual model
  • How to align the source feeds with the EDW physical structure

Lack of business understanding of the data and how the corporate data model represents it.

  • Who owns the data?
  • Where does the data enter the process?
  • By whom / what process?
  • What happens to the data on its journey?
  • Does the data change, get amended, be checked / go to different places?
  • Where does the data end its journey?
  • Who uses it?
  • What is it used for?
  • Does the data / report get changed before being used?
  • Does the data / report provide accurate information or is it used in an appropriate way?

We have all heard the term garbage in, garbage out – Lousy data quality is probably the biggest risk.

I once worked with someone who was more interested in getting the system implemented that considered the data that will be used.  The company ended up with a “toxic dump of data” which took over 12 months of manual analyse and correcting.

Much longer than if the data had been understood and rules had been written up front before loading into the new system.  A delay yes, but ensuring the system provided accurate information than the lack of trust the new system would provide after “going live”

Lack of good data architecture for the warehouse and, in particular, lack of good documentation of the data architecture.

Data profiling / understanding data quality only happened as a result of finding a problem. Data quality is not taken seriously, no or ineffective data profiling.

  • No data owner
  • No data architect who understands the relationships between various sources

Traditionally business rules are buried in code. That’s a bad idea if you want to gain and retain trust, and is inefficient as the rules will need to be enhanced, expanded, further developed or added to.  This will build in future-proofing and extensibility in to the solution being built.

Share your experience

There are just a few ideas on indicators that could signify a failing project.  I am sure whoever you speak with will have their own list from their own experience. Feel free to share your experience and expertise in the comments of this post.

See you next month for the final chapter in this, what has become, a long list.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: