Prior to consulting, I managed multiple IT projects for the publicly traded company where I was employed. I learned that while it’s possible to manage an IT project internally, there are some challenges. If you’re considering running your own project, here are a few key points you should think about.
Everybody has a day job, including the Project Manager
Unless you’re a large enterprise with a dedicated Project Management Office that dispatches project teams across the organization when needed, there’s a good chance that everybody on the project team will already have day-to-day responsibilities – including the project manager.
That was my situation. I ran operations for a division of the most profitable business unit in the company. My team of 70 and I were responsible for:
An in-house call center serving 400,000 customers
- A relationship with an outsourced call center
- A marriage mail database of more than 2 million addresses that our USPS rep called “the best in the city”
- Sales support
- Logistics support
- Our division’s enterprise system
When the last project I managed was launched, there wasn’t even a discussion. It was mine. We were replacing our division’s enterprise system. There were some very ugly politics involved prior to the project that I’ll detail below.
I tapped two of my employees for the project team and added 5 more employees from other divisions, plus several fractional employees from IT. All of us had day jobs, which we continued to do for the duration of the project. We completed the 18-month project on-budget and one week over the original timeline.
This seems like the poster child for a successful internal project. But even with successful project outcomes there are plenty of lessons to be learned.
There’s more to the selection process than meets the eye
Replacing our enterprise system was part of a company-wide standardization project where every business unit would install the same system for this particular discipline in each organization. I was part of the system selection task force. When our task force convened in the offices of one of the business units, we participated in several days of vendor demos.
Without getting into some very unpleasant details, the task force ended with very little unity. Serious scrutiny of the vendors was discouraged and dissenters were squashed. The vendor choice was suspect, with very little transparency into the final decision process. Because of a very complicated political environment that deteriorated even more over the course of the project, we were off to a rough start before the ink on the contract was dry.
Typical Objectives for Complex Projects
If you’re going to manage your own project, there’s nothing more important than defining the desired project objectives, including:
- Desired customer experience
- Operational improvement
- New tech-enabled product offerings
- Cost savings
- Employee satisfaction
- Improved visibility into important metrics
- Defining the desired vendor relationship
Getting your team to agree and remain aligned behind these objectives is imperative.
This all needs to happen before the Request for Proposal (RFP) is written and the first vendor is contacted. We often see the stat that 70 percent of complex projects fail. I think this factor is a big contributor. Projects without team alignment and agreement are stillborn because team members don’t know what they’re after, what success looks like, and what they’ll gain when the project is over.
Consequently, the first consideration is: Do you have someone in the organization who can draw this information out from all stakeholders, synthesize it, and put it in a format that can be used for the RFP process?
The Day Job
What happens when project team members are stretched between the project and their daily obligations? The short answer is that the day job suffers.
During my project, I abandoned my most important job as a manager: developing the people who work for me. Instead, my focus was 100% operational. I barked orders with only occasional explanations of “why” just to make sure nothing fell through the cracks. But no time was devoted to equipping employees to do better work or be prepared for a promotion.
For those folks on my team, we continued to provide support for the system we were replacing all while planning its demise. The rest of the people on our team took on more work as the two folks on my team and I spent increasing amounts of time on the project.
While I could insist that the folks who worked for me devote time to the project, I couldn’t do the same for the folks I recruited from other divisions. As you would expect, their “day job” boss wanted them to prioritize the day job and work on the IT project only as time allowed.
If a project team member quits or has an extended leave, we jeopardize the project.
In the Bible, Jesus observed that “a prophet has no honor in his hometown.” That’s also the battle an internal project manager faces. Our project team was very dedicated and did a really good job, but it’s much tougher for them to respond with urgency to an internal project manager with whom they are familiar.
And then, there are the “fires.” Every division, every department, every workgroup has them. They suck up resources and scream bloody murder until they are resolved. They regularly steal project resources from everyone involved directly and tangentially in the project.
There’s another interesting risk factor here: Because we tap resources that are already busy, we have no margin. We’ve already asked the person to contribute and, implicitly, we’ve asked everyone around them to dive for the ball to take up any slack that occurs. If a project team member quits or has an extended leave, we jeopardize the project since it’s very unlikely that any members of the project team have a backup on their project tasks.
Maybe the most important internal exercise in a system implementation project is understanding and documenting processes. And one of the biggest surprises you may encounter is when two people who have intimate knowledge of the same process don’t agree on what it is.
Many times, an internal project manager is also a business analyst on the project. It’s going to be their job to understand and document these processes. In some cases, they might also be the Subject Matter Expert (SME) on parts of the project.
The combination of these things is sometimes a hindrance in getting to the truth (which is essential). An external project manager sometimes asks more probing questions in documenting processes. They don’t know “what Mary does” or know pieces of institutional knowledge that are so widely held in the organization that everyone (including the internal project manager) doesn’t even think about documenting them.
Vendors vend. Sometimes they have sophisticated project plans and stellar project skills, but sometimes they rely on the project management of the client or a third-party project manager retained by the client.
I still vividly remember a vendor I defended enthusiastically over 20 years ago. The founder was brilliant and the software was phenomenal. Too bad he wasn’t as good at the business side. I defended him all the way up to the time he led his company into bankruptcy.
What Can Go Wrong
I’d be remiss in discussing managing your own project if I didn’t mention the fallout. If the project fails, it can be a stain on the reputation of talented people in the organization. It might stop them from any future upward mobility if people attribute the project failure to them.
Relationships can be wrecked. Projects are hard. Deadlines are tough. People can get their feelings hurt.
Moving Forward and Taking Initial Steps
Managing your own software project isn’t impossible. But you need to go in with eyes wide open.
You need strong executive sponsorship. Everyone in the organization needs to know the big boss wants this done or you’ll never get managers to offer up resources for the project.
You need to be ready to elevate the project manager and let everyone know their authority is on par with department heads or division heads, or whatever it takes to show people that they have clout to get the project done.
You need to be willing to weather project delays when “day jobs” must take precedence.
If the project manager and team don’t have project experience, you need to be willing to let them learn on the job. That will most likely entail extra time and extra expense. The good news is there will be some big upside if they make it through, thanks to their new skills and increased value to the organization.
You’ll want to evaluate the political climate in your organization. Projects almost always cut across silos. Since an internal project manager comes from “somewhere”, is there an appetite to let someone reach into multiple silos and enlist peers, superiors, and subordinates for the project team and to exercise a measure of control over them?
Finally, if you’d like to see internal project management become a core competency of your organization, you might want to engage an external project manager for a “training project”. Take your hand-picked future project manager and let them learn from an experienced project manager as you implement a software solution.