�����Ƶɫ

Your IT Project Cheat Sheet

What does it take for an IT project to be successful? If anyone knows, it’s Lori Rainery, our Director of Program Management. In her time so far at �����Ƶɫ | AppRiver, she’s managed innumerable IT projects, both small and large. Her claim to fame, however, is that she’s led us through not one, but two domain merges, a herculean effort that most people don’t experience once in their career.

Naturally, when we decided to write a blog post on IT project planning, we knew we’d have to get her input. Here are Lori’s main lessons that she’s learned planning IT projects over the years.

Understand the stakes (and the stakeholders)

No two IT projects are created equal. There are a number of nuances that shape who should be involved in your project and which models you should use to plan it.

First, let’s consider greenfield versus brownfield IT projects. Greenfield projects are defined as those that are completely new, i.e. not building on an existing system or tool. Conversely, brownfield projects often pick up where an old project left off, or involve making changes to an existing system.

As you can imagine, the stakes—and stakeholders—for each of these scenarios are quite different. As Lori tells it, “When you’re creating something completely new, more stakeholders are involved. You need to have the right experts at the table, and you may need to bring in a consultant to lead you through the project.”

Greenfield projects also undergo more scrutiny. In other words, the stakes are higher. “There’s usually more executive involvement for projects like these, which tends to mean a more formal project plan is needed,” says Lori.

Get your plan together

The planning and accountability models for each type of project are different too. According to Lori, “For brownfield projects, everyone usually knows the lay of the land already, so a RACI model will do.”

RACI, for the uninitiated, is a planning model that stands for “responsible, accountable, consulted, and informed.” In a RACI matrix, each stakeholder is listed out, as well as each project task. Then, for each task, each individual is given one or more letters in the “RACI” acronym. For example, a project manager would be responsible and accountable for holding the project kickoff meeting, while other SMEs may be consulted in the kickoff planning, and others will merely be informed when they attend the kickoff meeting.

Greenfield projects, on the other hand, usually require more formal planning and allocation. For this reason, Gantt charts are used more frequently, which offer a much more involved timeline. Looking at a project Gantt chart will tell you when each task begins and ends, as well as the tasks that depend on one another in order to move the project forward.

No matter the size of the project, it’s important to understand the budget requirements and constraints. Greenfield projects usually require more resources and allocation, which often lead to a higher budget.

Decide how much tech debt you’re willing to take on

Another notable difference between greenfield and brownfield projects is the amount of tech debt involved. This refers to the cost of having to redo things later by choosing an easier, more limited solution now.

As you can imagine, people are usually more willing to take on tech debt with brownfield projects. “It is harder to course correct when you’re working with something that already exists, but brownfield projects allow you to apply lessons learned from previous projects,” says Lori. Updating old technology or systems also allows you to work with a known quantity, and the implementation is usually less involved.

Regardless, Lori suggests that whether you’re continuing old work or taking on something totally new, to make sure what you’re working with is scalable, efficient, and as automated as possible. The more you can avoid having to manually update things in the future, the better.

Understand the use cases

For any IT project, it’s important to understand exactly how the system, tool, or software will be used, and by whom. As Lori tells it, “Lots of people are tempted to jump in head first, but sometimes you need to slow down and focus on all the moving parts ahead of time.”

The type of project management model you choose can heavily influence this process. The two most common approaches are agile and waterfall, and while both have their merits, they’re also very different.

Agile project management is a more iterative approach that breaks a project down into two-week sprints. It allows for lots of course-correction and collaboration throughout the project lifespan, which is great. However, its looser nature also means that at times, use cases are not fully worked out in advance. “When it comes to project work,” says Lori, “Agile has taken the forefront, but some aspects of waterfall should still be used to really capture requirements at the beginning so that you’re not uncovering them mid-cycle.”

A waterfall approach is much more linear and detailed. It requires distinct, sequential planning rather than everything happening concurrently. While applying this level of detail to an entire project may not make the most sense, there are definitely certain phases, like planning and resourcing, that can benefit from it.

Keep your stakeholders engaged

Perhaps the most challenging part of managing any IT project is the people aspect. That is, keeping everyone involved accountable and aware of what’s happening. According to Lori, this is an ongoing effort that starts in the kickoff stage. “I always invite everyone to a project kickoff,” she says. “If a person attends and decides that the project doesn’t affect them, they can at the very least elect to look at the project dashboard for updates.”

For people who are more involved, the kickoff is a great time for them to identify when they may need to be looped in. “From there, I can set reminders to notify people when it’s their turn to jump in,” says Lori.

Overall, automation is an important part of keeping people accountable. “You have to be very proactive, and there’s a lot of follow-up required to make sure people are doing what they said they would,” says Lori. “As a project manager, the more you can automate, the better.” This includes setting time-based reminders to follow up with people whenever an action is required on their part.

Be flexible, but hit your target

You can plan every aspect of an IT project down to the letter, but according to Lori, a successful execution ultimately relies on your willingness to be flexible. “You always need to read the room and adjust accordingly,” she says. “Often projects fail because the PM has a routine that doesn’t work with their stakeholders.”

If it’s clear that engagement is slipping, or that people are dropping the ball on their tasks, Lori’s advice is to keep communicating and keep people looped in. “Even when there’s the slightest slip, don’t be afraid to ask for help from the stakeholders who can jump in,” she says.

If you plan well, automate appropriately, keep in contact with the right people, and allow for the plan to change if it needs to, you’ll be on the right track. But remember, no project is a true success until the thing you set out to do has been done. “You can hit all your success criteria, but if everyone’s done what they can and you still can’t use a new software until next year, did you really succeed?” says Lori.

Whether it’s a true success or not, every IT project is a chance to learn, improve, and find out what motivates your team—all good things as you forge ahead into the future of IT.