Manage Learn to apply best practices and optimize your operations.

Traits that make for an effective financial IT project team

Every CFO wants a financial IT project team that's able to execute complex projects successfully. Learn what characteristics to look for when shaping your team.

Here's part of the duties listed for a director of IT project management job opening at pharmaceutical giant McKesson:

"Successfully coaches, mentors and leads resources in the continual improvement of McKesson project financial management practices. Establishes a clear definition of team and individual success and failure. Establishes effective means of measuring performance. Provides continual coaching and feedback in an effort to meet team and McKesson IT goals."

Beneath it all is a quest to build an effective IT project team able to execute complex projects. This creates the edge, the tipping point, the extra competitive oomph that everyone is after. Leading the team to interact and communicate is at the bedrock of effective IT project team implementation, and it begins with the right person to lead such an effort.

The IT project team -- from the client leadership on down and through the leadership of the vendor team -- must be good communicators with the right charisma to collaborate well.

Consultants who explain why so many IT projects (many of them financial) go wrong say the problem is a communication breakdown between the many players on the field -- from the accounts payable clerk to the developer.

Creating a team that communicates and collaborates well

So, how do we wire an IT project team to communicate and subsequently collaborate?

"What we're finding more in an IT setting is older generations were taught how to write, whereas the younger generations write how they talk," said Ken Perlman, an engagement leader with the management consulting firm Kotter International. "As younger talent enters the workforce, employees are using their own voice in their writing. When building a team, different interaction methods must be created -- either live or in person -- in the same physical space or in a video conference. Everyone on an effective team must know each other's voice because there's a certain level of personal tone in their writing."

This voice may cut across different capabilities. But proceed with caution when assuming that all are savvy in voicing their concerns across all platforms.

"Ironically, the connection that younger people have through social media produces a sense of connectivity that isn't there," said Gardner Heaton, a consultant with Kotter International. "Some teams might not have enough time to build those deeper relationships. It's easy to assume that all team members are on the same page over a social platform, but this might not be the case."

What happens when communication fails

Several years ago, commercial outdoor furniture seller ParknPool hired a firm to implement a new ERP system. It ended in a fiasco.

The client and vendor weren't on the same page from day one. The project is what ParknPool leadership attributed to a year of financial loss. The vendor was brought on to boost a financial infrastructure that had relied mostly on QuickBooks. Midway through the project, managers complained they couldn't read a profit and loss statement because their financial reporting was so botched.

Although it's hard to pinpoint what could have prevented the project from failing, clear communicators on all sides of the project certainly couldn't hurt. Filling the team roster with outstanding communicators and collaborators might have prevented the fiasco.

Team building centers on communication, team structure

When it comes to complex project team building, it's all about communication and team structure, according to Lawrence Putnam Jr., co-CEO of QSM. Putnam's advice, based on company research: Think small. He advised that you keep the team as small as possible while maintaining the necessary skills and backup to significantly reduce communication complexity.

"As a team grows from two to four people," Putnam said, "the pairwise communication paths increase from one to six and keeps increasing exponentially as we add team members. The more paths we have the more chances for miscommunication, which shows up as mistakes and rework for team members."

Structure the team and then structure team operations. Put some thought into how the team functions, manages expectations and operates.

Financial IT projects notoriously have long, slow and complex deliverables. To keep pace and maintain patience by all, the IT project team should meet regularly. They should ensure their roadmap fully supports the objectives set forth at the project's outset and do so with meaningful milestones all along the way, advised Sondra Leibner, senior consultant, TayganPoint Consulting Group. She also recommended that the team periodically re-examine progress and ensure that things are heading in the direction of team objectives.

Keeping a project moving depends on team dynamics

Financial systems are fragile and rely on many moving parts -- particularly an ERP system. They often touch many different departments across a company from accounts payable to purchasing and materials. Moving down a progressive path depends so much on team dynamics -- not just between each functional department, but between each department and members of the IT vendor team responsible for development and implementation.

For financial, accounting and payment environments, it's important for implementation team players to target short-term wins. Set incremental goals to tackle outcomes and deliverables that are long and complex, advised Perlman.

Tackling outcomes and deliverables is important for financial IT project managers today. That's probably why McKesson seeks not just a project manager but also a coach who can lead, mentor and listen.

"Overall, a leader must ask teams how they can better accomplish the task instead of simply delegating," Perlman said. "This creates a collaborative environment and the team sets a more aggressive goal than the leader, creating a double-sided benefit."

Next Steps

How to boost team collaboration

Steps to resolving team conflict

Rewarding team members builds morale

Dig Deeper on ERP financials

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

What best practices do you use when creating an IT project team?
I’m not a big fan of “best practices,” but one thing that I always look for is camaraderie among the team members. This was long before I ever saw Margaret Heffernan’s TED Talk on “Why it’s time to forget the pecking order at work.”
I highly recommend Gerald Weinberg's book "Managing Teams Congruently". A few excerpts.
The Blaming Organization
When an addiction becomes sufficiently widespread, it becomes part of the culture. Just as a culture can be addicted to drinking coffee or chewing betel nuts, so can it be addicted to blame. Among software engineering organizations, blaming cultures are the most common type, which is why their cure is essential if software quality is to be improved.

The Reusable Work Unit
The idea of reusability is not new for the manager with technical experience in software. When code used in one place can be reused, the savings can be enormous, as can the increase in reliability and decrease in variability. Once we have fabricated a collection of useful, reliable, and reusable modules, we are prepared to lower the cost, raise the quality, and improve the predictability of software development.
Just as reusable components are the basic units in hardware and software development, the software team is the basic design unit for software engineering processes. The job of the manager is to create, nurture, and maintain the teams that can be configured and reconfigured into reliable, predictable projects.
These are all very desirable traits, and point back to how the social interactions of the team play into the team’s success. That’s also one of the (historically) bigger problems that many IT teams face - it used to be that people went into IT because they tended to work better with machines than other people.