What Finance Leaders Should Know About Tech Projects - Part 2

Getting Started

The previous post in this series covered some of the major pitfalls business leaders fall into when approaching technology projects, as well as how to avoid them. While that may help leaders feel more comfortable thinking about the process improvements they need to make in the future, and how to prepare themselves for execution, there’s still the problem of executing the project.

Too often, business and finance leaders are hesitant to get projects off the ground because they simply don’t know where to start. What follows are some prescriptive steps and strategies to move projects from the idea stage into the action stage. Keep in mind that there is no off-the-shelf approach, and that each company — and even each project — will look different. But in one way or another, the following elements will be important to consider.

Above all, make enough time to dovetail your projects with your regular work, and if you have predictably busier times, avoid setting major project milestones in tandem with those times. Projects will go off the rails when other things get busy too.

THINK STRATEGICALLY

Software projects should serve long-term goals rather than being directed at immediate pain points. If done well, they’ll take care of many surface issues, but that shouldn’t necessarily be the focus out of the gate. Remember, knee-jerk reactions are often expensive.

PUT TOGETHER THE RIGHT TEAM

Project stakeholders and sponsors must be involved in project planning. Sponsors are typically business and management personnel, folks who ensure and bolster the project’s alignment with the larger business value it’s intended to create or improve. Project sponsors must have the time to dedicate to your project, which can be difficult given their deep involvement in other aspects of the business.

And of course you need a Project Manager — you cannot shortcut here, so get a bona fide, dedicated PM on your team.

Involve your entire team in the project from the very beginning in order to set the time expectations of the project. Just setting a deadline does not guarantee that your team can meet it. Your PM will be pivotal here. In fact, the deadline is not just set, but rather derived from the amount of work on the project as planned by the PM, the team, some key stakeholders, and the project sponsors. You need the context of the full project before you can ever set a deadline. In order to do that, you need actual input from the team on the project. You can see fairly easily that much is involved in setting a deadline, and arbitrarily setting one based on when you want a project to go live is a recipe for failure. It just doesn’t make sense.

LEARN WHAT SOFTWARE IS OUT THERE

One of the best ways to do this is by experimenting with free trials. If you’re interested in robotic process automation, sign up for UIPath or Automate Anything (or another app). If you see visualization software solving problems for you, get a free trial of Looker or Tableau. But know that these trials are only skimming the surface. The devil’s in the details, as they say. Free trial software is a bit like a 15 minute test drive in a car: you get little or no sense of what it’s going to be like for an 8 hour drive — or after 70k miles.

Research is crucial, and quality research takes time. Your PM, project sponsors, and dev team should all be part of this selection process, since only together will they be able to negotiate the limits and possibilities within which the tools need to fit. When it comes to software selection, you and your whole team should look — long and studiously — before you leap.

You’ve Looked…Now Leap!

Regardless of the important points above, you can’t get started unless you get started. And uncertainty is the biggest known barrier to kicking off a project. If you notice one thing, it’s that a majority of the points outlined in this post have to do with reducing uncertainty. In the case of business software, what you don’t know can hurt you. And it often does. Acquiring and documenting knowledge is a key to project success. It’s why having the right people is so important.

Many of the things we’ve outlined are aspects of your Project Plan. This is where you formally identify and assess your risks. And it’s where the importance of a Project Manager cannot be understated. Your PM is your risk management hero, the person whose expertise is leading change processes and mitigating many of the pitfalls we’ve described in this and previous posts.

You can see, then, that the liability shifts from making mistakes or taking undue risks, to getting the right person to mitigate those things. That PM superstar will also help set the expectations of the project much more realistically, which can go a long way toward avoiding dangerous shortcuts.

Going into a tech project, you’ll almost always find that it’s more detailed, more expensive, and much slower than your initial expectations. Preparing for this early will help you slow down and prepare for unforeseen complexities. Invariably, things will be worse if you try to take shortcuts. Shortcuts will backfire.

In the end, you’ll look back and realize that what seemed expensive and time-consuming, complex and frustrating, was actually a major long-term value. A little foresight can be gained by always keeping in mind that hindsight is 20/20. And if you keep that perspective, choose the right people, and choose the right time, your likelihood of success increases greatly.