The pain of IT projects … here’s a first aid kit

Jacques Malan.

---

When it comes to IT projects, none are ever seamless, most of them are delayed and almost all cost more than initially estimated. Here is a handy list that I use to remind my clients of the fundamentals:

Understand the requirements

The success of any project comes down to a thorough understanding of the requirements. Most businesses start with some kind of high-level document (eg. project charter/Initiation document, business case or statement of work, etc) of what the project aims to achieve, but this usually doesn’t cover the different needs of all the users.

• Make enough time to document requirements.
• Conduct proper reviews – don’t rush sign-offs!
• Don’t neglect non-functional requirements: For example, define system performance expectations upfront.
• Summarise requirements in an Excel sheet so that is easy to reference and prioritise. (NOTE: Later in the project, this becomes a useful checklist for things like user acceptance testing)

Use the opportunity to improve business processes

Simply lifting and shifting your existing business process onto a new technology platform just brings the same issues and end-user pain points. Most so-called “IT” projects turn out to eventually become “business transformation” projects anyway, so incorporate this from the beginning.

• When conducting business process redesign, aim to streamline and simplify as much as possible. Simplified solutions are actually more adaptable to complex underlying business processes.
• Don’t argue “because we do it this way now, we must do it in the new system”. Nonsense! If you had a blank canvas, what would you do?
• Use the new technology’s “out of the box” functionality as much as possible and work backwards: Think solution-driven, not requirements-driven. Think maintenance. Think sustainability – the next big software version upgrade is closer than you think.

Know your stakeholders, and use them!

While consultation with all stakeholders on all levels are important, it’s equally vital to have visible sponsorship of the project at the executive level. This individual should be actively participating in SteerCos at least. A successful project relies on leadership that is invested, and is available to provide input whenever necessary, including having the “tough conversations” that are necessary to challenge assumptions, ensure alignment and get things moving.

• Identify all stakeholders (even indirect ones) as well as frequency of communication.
• The sponsor should be visible and engaged.
• This role should be filled by an executive.
• The sponsor function could, however, be delegated to a “Programme Owner/Lead” which should be a very senior person that is respected and understands the business process (and especially the outcomes required).
• Have the tough conversations upfront. Don’t shy away from confrontation. Things will only get worse later.
• Secure / encourage buy-in by doing proof of concepts, system demos, etc. Mock it up in Excel if you have to. People like to see it to believe it.

Choose a “partner” not a “vendor”

• Your IT supplier should be a trusted partner, not merely an IT vendor.
• Obtain references from companies in your industry that have performed similar projects, or from your peers at companies in different industries.
• Look for firms that are beyond the “Big 4” for some niche skills and competitive rates. (NOTE: you can always get a high-profile firm to perform quality assessment(s) on the project, but use your internal audit function first, should you have one).
• Go fixed-cost always, but have room for maneuvering and negotiation.
• If every supplier meeting becomes a fight, walk away. There is lots of competition in the market.
• Have a project manager that reports directly to you.

Budget and resources are EVERYTHING!

• Allocate and approve sufficient project budget. If you are going to do something, do it properly.
• Make sure you have enough resources and enough skilled resources.
• To ensure capacity, dedicate key personnel to the project, full time. Even one solid business analyst can move mountains to facilitate functional and technical discussions.
• Have a plan to upskill internal resources and grow internal capacity.

Formal, dedicated project management is the key to success

Don’t underestimate the value of a formal project management function. Get someone who has done it before – they are usually quite keen to share learnings and templates. Free yourself up to let the experts do the job.

• Get a dedicated project manager. Preferably in-house and full-time. If not, then rather outsource a full-time resource than in-source a part time resource. Any Subject Matter Experts (SMEs) that are available part-time should rather be assigned as business analysts, functional experts or workstream leads, super users, etc.
• Get your own people to do the work and someone independent to facilitate (and police the supplier!)
• Start with a good plan. Set and agree on realistic deadlines for deliverables; list all major milestones and work backwards. Identify ALL dependencies. (NOTE: Don’t forget about other projects/ business initiatives that could impact your project, even indirectly).
• Validate underlying effort assumptions both ways. Plan for meetings, workshops, and administrative tasks.
• Maintain the plan. Once a week is not enough! An outdated plan is of no use. The purpose is to stay on track and allow room for corrective action.
• Manage changes formally. Push back on non-critical enhancement requests. Keep a “Phase 2” log.
• A realistic plan will always have some contingency, but it should be quantifiable and justifiable. (NOTE: use a risk-based approach to determine contingency).

If all else fails, make sure you have a Plan B in your back pocket.

Data, data integration and data reconciliation are the “make or break” of any IT project.

Yes I repeated “data” three times there… on purpose.

Data makes or breaks a project, or any system for that matter, and while it should take precedence, it’s usually one of the last considerations (after scope, design, build, etc).

• When it comes to data integration points, draw pictures!
• Start with the end in mind. For example, use existing reports to flush out data sources, data sets, comparatives, hierarchies, classifications, etc. (NOTE: Don’t neglect additional financial (disclosure) data and non-financial data).
• Avoid using sample /test /dummy data can as far as possible.
• Build your data “pipes” (integrations) as soon as humanly possible, so you can bring in source data at any given point in time. (NOTE: Large projects usually span 12-36 months. You need to be able to bring in fresh data during that period.
• When it comes to data reconciliation, it is probably worthwhile allocating a dedicated resource or two and/or even making this a workstream on its own. An audit/governance requirement is usually also fundamental, so ensure this is adequately covered.

Quality comes by testing… and testing again… and again…

A good testing plan is vital. A once-off test will achieve very little, and testing should not be done in isolation. End-to-end testing should be included throughout the project.

• A company should have a testing and training strategy in place. (NOTE: “Strategy” could simply mean a document with the fundamental approach that all stakeholders have agreed to).
• Use a “train-the-trainers” approach to grow internal capacity. Enable your super users ASAP.
• Think adoption: How will this system be supported in production? Again, think maintenance.
• Avoid over-reliance on external suppliers for basic product support. As the technology matures in your business (usually 3-12 months after project transition), opportunities for internal capacity should be there.

Change management considerations

This isn’t always formally included in IT projects but it may be worth some time to chat to an expert around some basics, even if they just provide workshops and templates that can be managed internally going forward.

• Chat to an expert – the first consultation is usually free.
• Get a complete proposal and then “cherry-pick” what you want from the list.
• At the very least, consult your HR department. I am always amazed by the under-utilised skills that are available internally.

One last thing: We are people, not machines

• Make time to have fun.
• Arrange team-building events and socials. (NOTE: this article was written during COVID-19 lockdown, but online fun activities should still be considered)

Ultimately, an IT project is like building a house. Build proper foundations. It’s only going to get more difficult later. And the changes are going to come as you see it materialise, so be prepared for the project to cost more and take longer than initially expected.

A successful project needs a project manager to establish the right framework and to bridge the gaps between business requirements, development team, and end users, removing clutter wherever possible and facilitating healthy debate along the way.

Most importantly, a successful project requires trust – trust in the ability of the experts implementing the system, trust in the business teams involved, and trust in the technology. No trust, no project.

Malan is a project management professional PMP® with over 10 years’ experience implementing financial systems.