Cookie Consent by TermsFeed Deliver a Previously Failed Project | WB Data Focus | WB Data Focus

How to Deliver a Previously Failed Project

Sarah Wenman-Bateson, October 2019

Project Team Together

The longer I work on IT projects the more often I come across this scenario. Initially WB Data Focus are engaged to deliver a project, this is quite exciting for us, a new challenge often with new clients, happy days! We arrive on the first day and the managers are really upbeat about how great this data project is and how it will transform the business. Meetings are duly set up with the business and then we come across this problem, no one in the business one wants to do it all again…

So, what do you do when there is a general reluctance with the client to try to build something where your predecessors failed? Here are my tips to getting the wider business team on board, easily and quickly:

Listen to the Business

  1. Meet with the business team as soon as possible, it is probable that many people will be too busy to attend as they have done all this before. Talk to those who do attend, listen to all their gripes about why the project previously failed and why they believe it will fail again. Then go and meet with all those who didn’t attend the meeting and have the same conversation with them too. Regularly review your notes to limit the chances of the same problems occurring again.
  2. When creating stories be mindful of the team members' perspective. Business users will understandably focus on their own element, however you need to take a holistic view of the process and create cross user / business stories.
  3. Go through the systems, spreadsheets, workarounds they are currently using, these will really help with delivering what the business want and expect. Never belittle these solutions, they have worked well for a period, sometimes a long time. Also, at this stage the business think their existing processes are 100% accurate.
  4. Listen to how the current solution could be improved, e.g. are the financial figures run once a day / week when they are required more frequently? Is it cumbersome working through many screens when one would suffice? Can you skip through the screens and save without completing all the required information?
  5. During conversations with the business try not to seem as though you are a salesman. It is very easy to talk up technologies to an audience who is not so knowledgeable, however no one likes to be out of their comfort zone.
  6. Get to know the team you are working with; they are probably great people. Try to learn what makes them tick, what do they do outside of this project? What is their ‘real’ role in the company outside this project? What are their hobbies and interests? It makes the role much more fun if you work with genuinely interesting people on projects. Also, you will find it is easier to talk to someone you like and connect with. This leads to easier communications, which brings good and bad feedback.

Agile Delivery

  1. Build up and order you backlog appropriately. Ensure that there are a few quick wins delivered in the early sprints to garner business support.
  2. Ensure that your deliverable cadence adds value each sprint and keeps the business engaged and momentum going.
  3. Establish the business domain experts who can define success criteria and ensure this is fed into each story. There is always a person in the business who the team see as being an expert and when they say everything is working the rest of the team will follow suit.
  4. Ask the business experts to provide test data, this will ensure their individual quirks are included in the system.
  5. Any issues need to be dealt with in a personable manner. I don’t believe lengthy emails sent to half the company are appropriate in this situation. Firstly, I am unsure they are read thoroughly, if they are read at all. If you have a question, phone the business expert or pop along and see them. I do believe it is good practice to confirm the specific details of the conversation with an email, this gives a chance for the expert to read over the details and ensure they are correct.
  6. When delivering, ensure the relevant business users and scrum team attend the sprint demo. This makes sure that everyone knows what was delivered. New systems are sometimes hard for the business to adjust to, however, buy-in and feedback along the way will help with the ease of integration.

Interaction with the Business

  1. Don’t pretend you haven’t been in this situation before. Explain repeatedly that it is quite common for a project to fail, people move on, budgets are cut, companies are bought out and the requirement changes, sometimes the expertise isn’t available to see it through. It is important to build confidence that you have worked in this situation previously and have delivered the project. If possible, show examples of work you have delivered before, or discuss other projects where you have delivered similar results.
  2. Keep interacting with the business, this is a fine balance, no one wants to waste their time at meetings which reiterated last week’s meeting, however regular interaction as a team helps bond the team together. I would suggest regular interactions when grooming the backlog stories. Also, be firm on blockers, work closely with the scrum master / relevant parties to resolve quickly.
  3. My final tip would be to get to know the IT department. Data projects are often run separately to the IT projects, but require the in-house expertise for servers, software and infrastructure. In today’s business climate IT departments are typically short staffed, without working at this business relationship it will be very hard to deliver the project.

Whilst it can seem daunting to start a project which has previously failed and appears to have little business appetite. I can assure you if you follow our advice and treat the wider team with the consideration you would like to receive, they will soon be onboard, and you’ll all deliver a successful project.