Let’s face it: IT projects are complicated.
They involve so many moving parts, and require a million different steps and phases to get a good final product.
Not to mention, you’re often working with or for non-technical clients or colleagues who don’t understand the amount of work required on the back end or how much time even small changes to a plan will add to a project’s timeline.
And things are always changing! New technology can arrive on the scene, making your work obsolete. A client might get wind of a competitor doing something radical and want to incorporate that into their project.
While things are always changing in tech, the methods that make IT projects—or any project—successful, have stayed fairly constant. Projects require planning, teamwork, respect, communication, testing, and, of course, the right tools and resources.
To help you and your high-functioning team complete your next project on time and under budget, we reached out to some IT project veterans for advice. Below, they give their tips for running better IT projects during every phase, from planning, to staffing and organizing, and finally to implementation.
Make a plan for your IT project
A project plan is like a road map. You might know what your final destination is, but it’s often more important to know how you’re going to get there.
According to our IT experts, the first key to a better IT project is planning, and no IT project should start without it.
Know what you’re doing and why
Before getting down to business, you and your team should look at your project from every angle, asking critical questions until every one is answered.
Every IT project has to start with a plan. What resources do you need? When? What are the critical path or high-risk items that require special consideration? Are all the key dependencies accounted for? Once the plan is in place, it’s time to start work.
But figuring out exactly what your team needs to do is especially important if your client or colleague requesting the project isn’t in tech, as Greg Morawietz, vice president of operations at Single Point of Contact, points out:
Fully understanding the scope of the project is difficult if the requester is non-technical. When you take a look at the problem from a technical perspective, you might realize that the request doesn’t align with the actual requirements, or that the technology that you have might not meet the requirements of the projects.
In other words, you and your team will often need to translate a non-technical person’s needs into a viable project for your engineers, developers, and designers. And in some cases, you might also need to let them know whether the project is even doable, given your resources.
To create this detailed project plan, Daniela Field, a senior solutions consultant at Mendix, suggests holding a kick-off meeting to help “set clear expectations on project vision, deadlines, and people’s roles.”
This meeting will also help “to clearly define what the end goal is, what the definition of done looks like, and outline the ‘why’ for taking on a project.”
Especially in an IT project, where there are lots of moving parts, it’s important that everyone on your team knows what their role is and what their priorities are. Clarifying these things at the beginning of a project rather than on the fly will hopefully help your team finish on time and under budget.
Make sure your plan includes room for changes
Once you’ve got a plan, try not to deviate from it. “Define what you need to do in advance and stick to it. Do not allow for project creep, changes, or methodology changes in the middle of the project,” Trave Harmon, CEO and owner of Triton Technologies, advises.
But Harmon is also insistent that not everything will go according to plan. So he has his teams plan for the unexpected by “allowing for overage for estimated time.”
That means understanding that your team probably won’t get everything right the first time around, and that’s okay. Or you might find yourself working with a non-technical client who doesn’t understand the scope of their needs or the state of disrepair of their systems.
Either way, Harmon says it’s important to “account for that kind of failure” and build time for mistakes, delays, and surprises into your project plan.
Pick a project management methodology
A project plan isn’t just a list of to-dos. In order to help your team through rough patches or even estimate the date when you’ll finish your project, you often need to adhere to a project management methodology of some sort.
The two most common methodologies are some form of Waterfall or Agile. While we could argue all day over the merits of both methodologies, I’ll let the experts elaborate on what’s worked well for them.
A digital interactive project for an ad agency should always be Agile, because creative work demands an iterative process to achieve the best results. Creative people are generally visual, so incremental results with constant feedback ensure a successful outcome.
Any project for a large organization, e.g., over $1 billion a year in sales, needs to be Waterfall, with the associated mountain of artifacts. This is necessary to ensure a diverse constituency spread across multiple functional units agrees in principle with what is being built and how it will affect them.
Successful projects that I have been a part of all used an Agile approach. Agile is a methodology that involves collaboration, accountability, and continuous improvement. Prototypes will be delivered to the customer or client in two weeks or less. This is an advantage for clients that want to market new products earlier.
Ultimately, whichever methodology you choose to adhere to should be the one that works best for your team while also helping you achieve the best results.
Add great partners to your team
Finally, before you put your heads down and get to work, take a moment to look over your team to see if there are any gaps that might need to be filled along the way. Be honest about your capabilities. And if you need outside help, we have some expert suggestions of where to look.
Richard Lowe, writer and former director of computer operations at Trader Joe’s, shared his experience in outsourcing to veteran groups, citing their proven experience working on large, often complicated projects:
I found [ex-military teams] to be extremely stable, very methodical, and incredibly honest. When I needed something done, they’d do it. If they made a mistake, they’d own up to it and take corrective action.
Harmon also suggests “aligning yourself with great partners” to get the best results. “If you’re moving a data center, become a partner with the electrician, the moving company, and make sure that everyone knows what they’re supposed to do and how to do it.”
He suggests finding these partners by using some age-old relationship-building methods: “Call, meet in person, go to networking events.”
Essentially, there’s no shortage of great team members if you know where to look.
Organize your team
So now that you’ve got a plan and all your team members in place, what’s the best way to organize them? Should you designate one leader to rule them all? Establish a flat hierarchy and let a few natural leaders shine?
Much like project management methodologies, the way you organize your team will often depend on the type of project you’re working on and who the project is ultimately for.
Whatever your project, though, Robbins points out that one of the most important elements of a team is balance:
A team of all superstars will either argue themselves through the budget or produce something incredibly elegant that serves no purpose. A team of juniors will burn the budget exploring tangents and learning how to do things. A balanced team has one superstar firefighter, one senior process guy, two to three mid-level developers, and one or two juniors.
Putting a team together that’s balanced in terms of experience and seniority ensures that you have a few experts on your project while allowing your newer, less-experienced employees to learn from them. That means you spend less time training your “juniors” in hypothetical scenarios, giving them hands-on experience with people who know what they’re doing.
But once you’ve put together this balanced team, who do you pick to be in charge? Robbins argues that, “The best team is the one where you chose no leader, and the leader emerges after a few days. The cream really does float to the top.”
While this natural leadership model might work for some teams, others might need a more guided approach. Robby Emmert, a software developer for CQL, recommends putting senior developers in charge of client projects:
This way, decisions are always being made by technical staff. Non-technical project managers monitor progress and help audit budget and billing, allowing the developers to focus solely on adding value to the client.
What does that mean for how Crisan’s team’s function?
I like to create code and teams that operate as a series of small interconnected objects instead of one big block of code and people. That means having developers who can own the entire feature being developed, including the design, the development, and the architecture of its code base.
And what does establishing flat teams revolving around a single feature mean for your process? According to Crisan:
Any feature can be changed and edited without impacting any other feature and the developer never has to waste time waiting for someone else to provide assets so they can continue their work.
If you’re working with a team of talented developers you trust to take on a lot of responsibility, Crisan’s organizational method might work well for you.
And if you look around at your team and find you don’t trust them with much responsibility, you might want to ask yourself why that is…
Create an atmosphere where team members feel trusted and respected
If you don’t trust your team members, there’s actually a pretty good chance they don’t trust you, either.
Trust starts from the top. Being in charge of a project doesn’t mean you just get to tell everyone what to do. It means you’re in charge of making sure it gets done well. And that often means recognizing the accomplishments of your team members and sometimes giving them the autonomy to do things their way.
Emmert cites one way his organization allows developers to be in charge:
We have a flexible culture, where developers have a certain degree of freedom in choosing tools and process. This allows us to optimize our process to each project in an intimately technical way, as well as allowing us to retain some terrific talent.
Kelly Bedrich, co-founder of ElectricityPlans, recommends giving your individual team members a personal stake in the planning phase, urging employers to “get your employees involved in creating contracts.”
While Bedrich admits that this involvement might not always be realistic for every project depending on confidentiality concerns or the needs of your clients, it’s worked out well for his company.
Each of my team participated in actually developing the contracts with the outside vendors and stakeholders. This let my expert-mode developers make sure that all the deliverables were included in the contracted work to their satisfaction. It also began to establish expectations and relationships between my developers and outside contractors. This fostered better communication, especially early in the project, which set the groundwork for better outcomes down the road.
Getting your team involved and engaged early could keep them engaged for the entirety of the project. And letting your team know that you trust them to bring in business shows them you respect their judgment and capabilities.
If you’re not quite ready or able to let your developers take the reins in creating contracts, that’s fine. As Brad Shaw, CEO of Dallas Website Design, points out, the important thing is to “foster a culture where everyone’s ideas are heard to allow more innovation to take place.”
And what are the consequences of hearing everyone out?
The project team itself becomes a lot stronger. Team members are far more open to suggesting and working through ideas if they know they’ll be heard, rather than thinking they’ll be shouted down all the time.
So when you’re in the middle of a large project where everything needs to happen quickly, how do you make sure that everyone feels heard and supported?
I blocked out two portions of my day on my calendar where my team was my priority. I would go see my team members, just dropping by to see how things were going. Almost always, I got questions that I wasn’t getting in email, team meetings, or phone calls.
She thinks checking in with her team and giving them a chance to be heard was part of the reason her teams “had far fewer issues that needed correction, and we brought the project in on time, in budget, and with both happy customers and happy staff.”
IT projects are inherently stressful, especially when you’re working to a tight deadline and there are lots of key stakeholders to appease. Maintaining a sense of humor throughout, being kind to everyone involved, and taking regular breaks makes it easier to manage stress levels and make sure everyone’s happy.
And niceness shouldn’t stop after a project is finished. Make sure to take the time to recognize your team’s achievements, both while a project is going on and when it’s over.
Field recommends the following:
At Mendix, when an application project goes live, we have a cake celebration where we have a party to celebrate the completion of the project with the people who worked on it. This is done not only to recognize the work the team contributed, it also helps to raise awareness about the efforts behind the project to other people within the organization.
And honestly, when has cake ever been a bad idea for winning friends and influencing people?
Keep the lines of communication open
Once you’ve paved the way for respectful interactions, you can focus on open communication.
Open lines of communication ensure that everyone, from project leaders to project underlings, knows what’s going on.
One solid standby for continual communication throughout a project is the “stand-up meeting,” which a few of our experts cite as being useful for keeping everyone on track.
Cortez also points out that, once you’ve established open collaboration and encouraged knowledge sharing, the team will feel as though “[they] will succeed and fail as a team.”
He points out that this strategy “encourages team members to openly discuss how to build or improve an item. This is where innovation increases and ideas are communicated openly without fear or reprimand.”
In addition to open communication throughout a project, Cortez also recommends “retrospective sessions for the team after the product review with the client.”
This is a meeting where only team members are present, and the point is to discuss “what went well, what did not go well, and what can be improved from the previous iteration.”
The point of the meeting is for team members to be honest and open with one another. While this does require thick skin from your team, it also helps to “break the ice between new teams and produces healthy conflict where all of the issues are out in the open for everyone to discuss,” Cortez says.
In short, the good, the bad, and especially the “needs improvement” should be up for discussion. And since you’ve already created an environment where everyone knows they need to respect one another, you should be able to reduce possible conflicts that come from these discussions, if not avoid them entirely.
Be prepared to bridge the gap between tech and the not-so-tech-savvy
Completing an IT project often involves working with people who don’t understand IT, whether that’s your client or members of other teams within your company.
Robbins points out that it’s important to choose wisely when it comes to who will represent your team to the client. “Developers typically have little tolerance for an effective client relationship, which involves a lot of relationship building and not much chest thumping or dry wit.”
While you might have some more socially savvy developers on your team, make sure you pick a representative who will be able to talk to the client in non-technical terms and can understand and empathize with their needs.
Those using the Agile methodology can also rely on the natural opportunities that come at the end of a sprint to showcase their prototypes. Field recommends holding weekly or biweekly progress reviews and demos with a client to gather feedback.
Put your IT project to the test
Before presenting a final product, make sure everything works like you think it will. Your team has put in so much hard work that it would be disappointing to walk into a presentation with a client, only to have an easily fixable mistake derail the whole thing.
Harmon describes the testing phase as “a lifesaver” and his organization’s “biggest and most important rule.”
He also cites a benefit of testing: “We have had projects actually wrap up weeks in advance because we were able to head off potential issues and work around schedules.”
Testing can not only help your team save face if anything goes wrong, but it can also save time and money.
Find tools that will complement your team’s processes
Speaking of saving time and money, this wouldn’t be a Capterra post if it didn’t include a few suggestions for software that could help you do just that throughout your IT projects. Below are a few systems IT experts use to keep their projects on track.
Emmert’s team has adopted React for their front-end web projects. “We’ve noticed a dramatic increase in usability and aesthetic quality, as well as dramatic reduction in time to delivery, which means more bang for our clients’ buck.”
Kilvington suggests Basecamp for project management because it “offers a dedicated and secure space to discuss our ideas, upload docs, share to-do lists and check up on everyone’s progress.”
Roberto Gonzalez, co-founder and CTO of Aerolab, says his team relies heavily on GitLab for unifying code, review, road maps, issues, and most importantly, continuous integration with Docker and Dokku,” application development and application lifecycle management systems, respectively.
What are your tips and tricks for better IT projects?
While the IT experts I spoke with had some great advice for better IT projects, I’m sure there are more out there.
Let me know in the comments below if you’ve got any IT project management tricks of your own up your sleeve
In the meantime, you can check out the articles before for more IT project management resources.