The Beginners Guide to Planning IT Projects that Fail

ESTIMATED READING TIME: 6 MINUTES

Is it just us, or have you noticed this too… IT projects have a tendency to fail?

Whether the project has a huge scope and significant budget, or it’s small and concise, there just seems to be an unwritten law in the universe that says things won’t go to plan, budget or schedule.

But why? Projects can have the most experienced BAs and project managers, yet we still see these types of project failures.

Here’s one things we know, from 20+ years of being the ones who get called in to help solve the “unsolvable” IT project failures: unseen forces do exist and are often just part of life, so we don’t think BAs and PMs are really at fault.

But here’s what we also know.

The likelihood of project failure, and the extent of that failure, are increased when projects don’t incorporate solid business information governance in their planning and management activities.

Here’s how a Failed IT Project story unfolds

A new IT project arises, and the B.A.’s do their scoping and defining, the modellers or architects do their basic estimates, and quotes are given.

Then the project gets the green light. The PM and her team set up the project via your business’s project management software or protocol.

And the project proceeds, through defining, designing, building and testing…

...until it doesn’t.

There’s trouble. Things don’t work. Data isn’t right. Reports from the project testing are all wrong.

And no one quite knows why.

Tests. Re-tests. Unpacking and re-packing the data, links, sources etc., etc. A lot of work, a lot of frustration, a lot of confusion and bewilderment.

Sound familiar to anyone?

From here, many budget and time extensions may be granted (we’ve seen this expand to years and hundreds of thousands of dollars), but still the C Suite see no ROI.

The project just doesn’t deliver the reports, figures, or vision over business activity that it was built to deliver.

The missing puzzle piece – project information governance

Here’s what we’ve learned in our years solving these kinds of issues.

Information Governance within your Business

We all know any form of governance is hard work, not fun and represents an extra burden on our already stretched staff.

Fortunately, or not, most of the time information governance is now mandatory, so we push through the pain, write information governance documents and tick the box.

Phew!

But this approach is a mistake - a mistake which can be very costly indeed. When we believe information governance is something with an end point…a document to write and a box to check…we do not understand governance and we put IT projects at risk of failure.

When governance is approached in this “with-an-end-point” way, it’ll never ensure the solid information quality needed to successfully build out IT projects.

True governance is ACTIVE.

It’s a BAU activity that must be continually monitored, reported on and actively promoted throughout the organisation.

Writing an information governance framework is just the first step.

Ensuring that the governance principles and processes are followed in day-to-day functions is vital – or they won’t happen.

So, without this active & ongoing side of information governance, IT project staff are set up to fail. There’s no guarantee that the information and business processes outlined in the business requirements are correctly stated or understood.

Information Governance within your Project

Once a business has solid implementation of relevant information governance activities as BAU, the understanding and use of information within IT projects must also be covered by those governance controls and procedures.

Information governance within projects starts with how the definition work is undertaken at the start of a project. But more than this, to ensure governance of your information is consistent across the organisation, definitions should be drawn from an organisation-wide standardised glossary, not just developed and used for a single project.

If an organisation-wide glossary doesn’t exist, the definition work undertaken at the start of a project should be used to form the beginning such a glossary. For future projects, this will ensure all business staff are using terms consistently across databases, reports and dashboards, which in turn allows IT project staff to understand what they are being asked to build, and to deliver it consistently across the organisation. This is all the result of governance.

Further, information artefacts, like the models, design documents, dashboards or the reports the project will create, should themselves have governance applied to them. This will ensure they are understood, that metrics used within them are correctly termed and applied, and that version controls and out-of-date information is archived and no longer used. That’s the part of information governance we call artefact curation.

Artefact curation will ensure any already-derived information being used in the IT build is fully understood, its weaknesses and suitability for inclusion in this project will be clear and, as a bonus, staff will be fully aware of all the currently available business information, which may affect the scope of the current build

Finally, when problems are discovered with business terms or artefacts, whether problems in previous builds or in the information itself, these issues should be raised and governed. This requires that the business terms and artefacts have solid governance hierarchies established, so accountability for resolving issues is straightforward.

When organisations have established this depth and commitment to information governance, projects have a head start in assessing scope and pricing accuracy. They are far more likely to succeed and avoid ending up with problem-ridden builds that cannot be fixed.

Information Governance in Projects is Not Project Governance

Most larger organisations have structured project management processes and this, at least theoretically, keeps projects consistently run and monitored. But project management rarely considers the requirements of information governance within the project scope.

We would argue that without it, your project is doomed – you’re building with insecure tools and your end point is likely to be plagued with problems.

Those in charge of IT projects should have a solid understanding of information management requirements within projects, and implement such practices into the project management itself, from the get-go.

Good Governance must be Monitored and Checked

Of course, while we wish that the act of writing governance manuals was enough to make people follow them, we all know that’s never going to be reality.

People just don’t like reading manuals. And people often don’t like following rules and regulations that add extra effort to their work, when they can’t see an immediate or powerful reason for it.

And governance activities rarely seem to have an immediate or powerful reason.

But the importance of aligning business processes to information governance requirements is too great not to be enforced. The risk is too high. The cost can be astronomically high. The frustration it causes can be incalculable.

Therefore, some form of monitoring and checking for compliance must be part of the project management landscape.

Whether this means information governance team members have some authority to check project activities, or whether projects have their own information governance accountability hierarchies, is less important. As long as someone is checking to make sure staff are complying with requirements, the active side of information governance is met, within the project.

How’s information governance management in your organisation’s projects?

We’d love to hear your experiences, whether your IT project managers factor in this kind of information governance, and whether you’ve experienced the benefit of it or the trouble that’s formed from the lack of it.

Join the discussion on LinkedIn