Click to learn more about author Aaron Fuller.

There’s an old techie saying I first heard from the programmers I worked with when I got into corporate IT work. “This would be a great job if it wasn’t for the users!” Of course, it’s just a variation on an old joke that could be applied to any profession; the hardest part of any job is when you have to answer to the people you serve.

I’ve never found any truth in that. I’d describe myself as personable, which is why I enjoy and cherish my relationships and communications with end users.

It’s the projects that are problematic, not the users.

Of course, this is every bit as tongue-in-cheek as the old saying. Projects are how we deliver capabilities to those users, aren’t they? Traditionally, yes. It’s certainly true that in order for us to give our users new and better capabilities we need to deliver infrastructure, software and data to result in a production environment. But the truth is, our ability to achieve desired results has more to do with what we call “change control” than what we call “project management.”

According to The Association for Project Management:

“Project management is the application of processes, methods, knowledge, skills, and experience to achieve the project objectives. A project is a unique, transient endeavor, undertaken to achieve planned objectives, which could be defined in terms of outputs, outcomes or benefits.”

I agree management is essential, especially to balance resources and demands using “processes, methods, knowledge, skills, and experience.” However, the second part the definition, or the “project,” is what I’d argue against, particularly “unique, transient endeavor.” There is truly no end to my frustration with the way organizations let their project-centered mentality ruin their chances to build ongoing, sustainably valuable systems. Personally, it’s my biggest complaint about IT careers. It is my biggest complaint about my career in IT.

What exactly is unique and transient about what we are trying to accomplish within the organizations we serve? Every organization has a mission, vision, strategy, stakeholders, and business processes that need to be supported with technology, applications, and data in a secure manner. Anything data professionals are delivering to clients or employees should be aligned with the changes they want to make in how they do business, and those changes will occur over time. I think I need to emphasize it again – not all at once but over time.

Project managers try to convince their business leaders that every software implementation must be implemented in a “big bang.” Anyone who has been involved in those types of implementations can tell you that’s unrealistic. So often, after 18 months or two years of dumping resources into a big implementation, the leaders will announce they’ve decided to switch over to a “phased implementation.”

I’ve always read that phrase to mean they’ve been smacked in the face with the reality that there’s really no possible way to get a big – or even mid-sized – company to flip the on- switch for their fundamental software and data at the same time. Besides, the needs won’t end when the project is over. There’s ongoing support, bug fixes, upgrades, and ultimately another big system replacement in 10 years. Isn’t it time that we let go of the idea that anything we’re doing is really all that “unique” or “transient?”

Instead of focusing on what is unique about each request for a change in capabilities from our users, perhaps we need to be focusing on what is common about them. What types of needs do our business folks usually come to us with? If it’s implementing new ERP software packages and updating existing ones, then perhaps we need to develop a program practice – not a project practice – with a roadmap that describes how that team will implement incremental improvements over time. If it’s better managing and getting more value for the organization’s data assets, then it’s a permanent Enterprise Information Management program that’s needed, not some one-time, huge, revolutionary project.

Don’t take this as an attack on project managers. I think the skills and methodologies developed by that profession over time have been extremely valuable, and there’s still a need for their talents. But their incentives and focus need to change. I think they should be given roles where they help manage the long-term changes to an area of business technology capability where they can build up their expertise over time.

This is what the best project managers have done. They don’t just know how to apply their PMI standards to a project; they also know the resources, work and specific risks. Let’s give our project managers the opportunity to be less transient themselves and build up an area of expertise by putting them in charge of programs rather than projects.

It’s time to stop thinking about our investments in IT as being projects that are delivered on a certain date and then cease to exist. There must always be a strategy in place to manage our capabilities and assets. Instead of building projects, we should be building pipelines for delivering new capabilities. Let the changes flow.