Peer to Peer Magazine

56 and every answer you get to that type of question will help you see where the technologies you are advocating for address real business challenges. And you'll have a good context for talking with management about that next project. It shows that you are not just saying "There's a really cool new technolo that we just have to have!" And I'd go a step further, to use some of what Lisa Bodell talked about in her keynote at ILTACON 2018 - Analyze how to put your IT department out of business, ask questions that expose your weaknesses and then you can design a plan to overcome those vulnerabilities. Lisa says, "Want better ideas? Ask better questions." Don't be afraid to ask anyone who will answer, do they consider your last IT project a success, and why or why not? The answers to that question will amaze you if you look at them in terms of how you can plan for real success in your next project. On how you measure project success and when you measure it, see that as part of your need to look at risk assessment, quality assurance and defining success metrics at the beginning of the project and again in each project phase. Assuming you have answered the question around the business challenge the project is going to address, ask these kinds of questions: • Who needs to help define success? Is the technolo going to be used by lawyers, other fee earners, professional staff, clients? Any and all of those should be involved in defining that success BEFORE the project is developed. • Does this technolo rely on other existing systems or applications to work, or does it form a base for other technolo to work from? Any point of contact needs to be identified early and plans made to ensure it plays well with others. • How will we test this technolo? Traditional software testing occurs after the system is developed and before the users are exposed to it. What if the testing plan was created during the requirements phase, allowing the technical and end user testers to be involved in the objectives and requirements? Then the testing plan could be adjusted as the planning continues and the success metrics for the project are fleshed out. If your first mistake was not asking the right question at the beginning of the project, don't let your second mistake be waiting to ask questions until it's too late, when you've developed the project and are now in the user pilot phase ready to deploy. By then you've accepted the risk of the project going forward and the boulder is rolling down the hill with nothing to slow it down. You can wait for it to crash or you can intervene to slow it down and make sure the path is clear. Back to the question about the risk tolerance of your firm. To be innovative, you have to try things, and that means failing sometimes. Don't be afraid to ask the questions in your organization about how well it can absorb project failure. The answers will help your focus on the front end of those projects, and build in the points at which you can turn back or abort, so you don't end up with a system that is not adopted by users, or doesn't work and needs to be rebuilt, or has to be abandoned. Put another way, is it more tolerable in your organization to fail a few times early in projects or fail spectacularly after a long, expensive process? A final note on questions to ask around emergent technologies, the "trendy" projects. Everyone wants to A S K I N G T H E R I G H T Q U E S T I O N S

• Cover